- From: Bijan Parsia <bparsia@isr.umd.edu>
- Date: Sat, 26 Mar 2005 17:22:13 -0500
- To: andy.seaborne@hp.com
- Cc: Yoshio FUKUSHIGE <fuku@w3.org>, "'RDF Data Access Working Group'" <public-rdf-dawg@w3.org>
On Mar 24, 2005, at 9:08 AM, Seaborne, Andy wrote: > Yoshio FUKUSHIGE wrote: >> Hi, >> >> I remember we discussed about the semantics >> accompanied with our reification syntax? >> (Am I wrong? Please excuse me) >> >> If my understanding is correct, the semantics of >> "reification" differs from RDF/XML and N3 >> (in the latter it might have to be called "quoting?") > > I believe that's right - graphs can be quoted. There is, afaict, quite a complex semantics that has never been even informally well or fully stated for N3 formulas. > Reification > (of statements) is the use of the reficiation vocabulary > rdf:subject, rdf:predicate, rdf:object. Yes, and, per the RDF Semantics document, there are very *little* semantics associated with them. They are just Yet Another Vocabulary (closer, really, to Dublin Core than to, say, rdfs:subClassOf; rather, more like rdfs:seeAlso) >> My question is which semantics do we accompany >> to our syntax (what was the resolution) ? >> >> Literal reading of the document leads to the answer >> of saying: "we mean the former, for it's syntax sugar >> for RDF reification." > > The syntact sugar is just for RDF reification. Some people > use it and the syntax should be a help to them. Applications > that do not use reification just won't use it. While anything that ecourages use of RDF reification is discouraging, this is quite reasonable :) >> But our syntax is so close to N3 (by now), I wonder >> if we step forward (out?) to quoting. Absolutely not. > The RDF dataset (GRAPH in other words) approaches this > for access to named graphs in the data. I've not yet had time to examine this in detail, but I presume it's inspired by the Named Graph approach of Jeremey and Pat and et and al? > I don't know what cwm (et al) does about matching quoted > graphs in a rule head. > >> In case we should not do so, I think commenting >> it(=the difference) in the doc is worth doing. > > I'm not sure how to do this. The document is about what > SPARQL/QL is, not what it is not. Including things excluded > can lead to confusion in the reader. A specification, to me, > is not a justification of the decisions, it is a description > of SPARQL/QL. [snip] I agree. Stating that it is there for RDF Reification should be more than enough. If I might digress, I'm not at all, in genearl, so very convinced by the total benefits of N3isms. Turtle isn't so very bad to write (and I remember encouraging Dave when he developed it), but if people *really are* going to confuse it with N3, then it's worth backing out. N3 is not baked as a logic langauge (I and a student are working on a formal semantics for it, but there are a *lot* of questions) and there are *lots* of other contenders. Even as surface syntax, it's not all that widespread. The main advantage Turtle has (IMHO) over rival sytnaxs (such as F-Logic style, as used in TRIPLE) is that the basic pattern of a triple is space delimited URIs or QNames. This is about as common as you can get. Abbreviates for repeated patterns are quite reasonable. But punching up to some of the other, *much* more idiosyncratic and surprising features (even the behavior of @prefix is worrisome) seems a bad idea. (I'm not suggesting reopening the Turtle decision, just expressing a reservation about walking further down this path.) Cheers, Bijan.
Received on Saturday, 26 March 2005 22:22:17 UTC