AaronSw: "With the new Patriot Act, the use of the GET instead of the POST method [will let] authorities can claim that the search terms are part of the URL, and that they get logged with the URL in normal httpd logging."
AaronSw: An interesting anecdote for the GET vs. POST debate. ;-)
AaronSw: An interesting anecdote for the GET vs. POST debate. ;-)
sbp: because of this bit of N3: "this :forAll :s, :p, :o, :q . :forAll = log:forAll . { :s :p :o . :p = :q } log:implies { :s :q :o } ."
sbp: O.K., there's a bit of a joke in there in that it's solvable by a backwards chainer...
sbp: but the fact is that parsers shouldn't be expected to make inferences in order to parse an N3 document!
sbp: the log:forAll and log:forSome predicates break rank: they are parts of the syntax that found their way into the model somehow
sandro: ths distinction of "making inferences" is fuzzy. All computer programs being executed are "making inferences" in some sense.
sbp: I mean the specific case of deriving new triples from triples already present in a document, whether that be via rules from some external document, a built in rule, or something else doesn't bother me. the fact is that the meaning of an N3 document should be completely transparent to a parser: a parser should just have to parse the document, not decide things about its contents
sbp: If you have to start worrying about the meaning of a document before you can parse it, then you're stuck, because you have to parse it in order to get the meaning. that's why using @prefix as a triple doesn't work either (I've demonstrated in an upcoming article why several models for this fail)
sandro: Sorry for the confusion. I agree viewing @prefix as a triple is a lousy design, etc. I was just being pedantic about your use of "inference".
sbp: It's a good point: I am rather poor when it comes to my correct use of terminology such as "inference" (I believe that bijan has taken me up on this before)
sbp: But I hope/believe that the jist of what I said above is discernable in amidst the terminology confusion :-)
sandro: Something like n3 should have a simple and clear grammar, such that you or I or Bijan can implement correct parsers easily. No question.
sbp: As DanC is keen in noting, the fact that N3 is LL(1) makes it easier for people to implement parsers. in fact, there is some confusion as to whether it is LL(1)
sandro: The issue of parsing quantification gets conflated between (1) n3 making it look like log:forall is not magic syntax, and (2) people thinking n3 parses to triples when it really parses to logical formulas (which I contend can be nicely mapped to triples, but that's an aside).
Seth: for a previous discussion of this topic
Seth: TimBl says "That if :x = :y in the daml:equivalentTO sense, then you can't assume from forAll x that froAll y too."
Seth: But why not? ... with {:x daml:equivalentTo :y} you just said that :x and :y denote the very same thing, so it follows that from forAll x you can assume forAll y. I don't get this :(
Seth: if {:x daml:equivalentTo :y} then you could always substitute :x for :y and visa versa.
Seth: in rebuttal to sbp's above mentograph of this :forAll :s, :p, :o, :q . :forAll = log:forAll . { :s :p :o . :p = :q } log:implies { :s :q :o } .
Seth: so the question remains: Why can't we express quantification as arcs between the variable and a formula ??
Seth: apparently there is a bug in CWM that barfs on this, so apparently instead of removing the bug, TimBl and company just decide to sweep the problem under some rug. I say we need to see quantification as triples, otherwise its not labeled directed graphs, but just wierdness.
Seth: B: KIF does a better job, at least it allows us to see the forAll: (forAll (?x ?y) (dmal:equivalentTo ?x ?y))
tim-lap: See explanation