Re: Semantics of Qurtle (N3 vs TriG), Graph Literals again.

On 4 Mar 2011, at 02:41, Sandro Hawke wrote:
> There have been several posts about how it's not clear what the
> fourth element means.  

That discussion should happen when [GRAPHS] has made some progress.

Best,
Richard



> I want to point out that N3 has an interesting
> take on the problem; rather than decide and declare a priori the
> relation between the triples and the extra URI, it lets the author
> decide and tell the reader via an RDF predicate (examples below).
> 
> So, here's a TriG document D:
> 
>    @base <http://example.com/> .
> 
>    <u1> = { <a> <b> <c> . }
>    <u2> = { <a> <b> <c>.  <b> <b> <c>. }
> 
> I think there are two main schools of thought about what this means,
> corresponding to whether we think u1 and u2 identify g-snaps or
> g-boxes.
> 
> Option 1 - We might take u1 and u2 as identifying g-snaps.  In this
> case, D is telling us that the URI "http://example.com/u1" is an
> identifer for a particular g-snap (abstract/mathematic set of one
> triple), which we can write down using this turtle g-text, "@base
> <http://example.com/> .  <a> <b> <c> ."  Similarly, it tells us
> "http://example.com/u2" identifies a g-snap of two triples.
> 
> In n3 (as I understand it; I don't think this part is formally
> specified), we could write this meaning like this:
> 
>    @base <http://example.com/> .
>    @prefix owl: 
> 
>    <u1> owl:sameAs { <a> <b> <c> . }
>    <u2> owl:sameAs { <a> <b> <c>.  <b> <b> <c>. }
> 
> Option 2 - We might take u1 and u2 as identifying g-boxes.  In this
> case, D is telling us that "http://example.com/u1" identifies a
> container of triples which currently contains one triple, as shown.
> We could reasonably expect that, barring things changing, we could do
> a GET on "http://example.com/u1" and get back the Turtle content,
> "@base <http://example.com/> .  <a> <b> <c> ."  If we got D from a
> trusted source, and for one reason or another we're not worried about
> things changing, we could skip doing that GET, because we know the
> result already.
> 
> In n3 (again, as I understand it), we could write this meaning as:
> 
>    @base <http://example.com/> .
>    @prefix owl: <http://www.w3.org/2002/07/owl#>.
> 
>    <u1> log:semantics { <a> <b> <c> . }
>    <u2> log:semantics { <a> <b> <c>.  <b> <b> <c>. }
> 
> ("The log:semantics of a document is the formula which one gets by
> parsing a [it]." [1] For "formula" read "graph", for our purposes.)
> 
> Are there other common meanings?  There are other relationships that
> resources can have with triples, of course:
> 
>  - a person can assert/claim some g-snap
>  - a person can be the author/creator of some g-snap
>  - n-ary: a person can assert some g-snap over some time range
>  - ... etc
> 
> but all of these can be done using the Option-1 (g-snap) or Option-2
> (g-box) interpretations, like this:
> 
>    my:Sandro eg:claims <u1> .
> 
> That would be defined to means either that I claim the g-snap u1 or
> that I claim whatever is in the g-box u1, depending on which solution
> we are using.
> 
> So, I don't know that it matter very much which way we go.  In my own
> coding, in part because I'm usually using a mutable quad store, I
> think of it as Option-2 (g-boxes), BUT I only use my own URI space (so
> it never changes without me knowing about it), and there's usually a
> set of URIs which I treat as immutable and think of as effectively
> being g-snap identifiers.  When I fetch stuff off the web, I store
> that explicitly, keeping each version as long as necessary, with its
> own URI.
> 
> I will note -- returning to a topic of some earlier emails -- that some
> of the use case for Qurtle can be addressed by just defining datatypes
> for the RDF syntaxes.  For example, we can write D in ordinary Turtle,
> with Option-1 semantics, like this:
> 
>    @base <http://example.com/> .
>    @prefix owl: <http://www.w3.org/2002/07/owl#>.
>    @prefix rdfsyn: <http:://example.org/rdf-syntaxes/> .
> 
>    <u1> owl:sameAs "@base <http://example.com/> . { <a> <b> <c> . }"^^rdfsyn:turtle
>    <u2> owl:sameAs "@base <http://example.com/> . { <a> <b> <c>.  <b> <b> <c>. }"^^rdfsyn:turtle
> 
> The quoting gets a little hairy to do by hand, both in Turtle and
> RDF/XML, but it's pretty easy for machines.  No special parser is
> needed, and systems which don't know this datatype will, I think,
> effectively ignore the triples, as they probably should.  If we want
> option-2 semantics, I think we'd need to make up a new predicate, like
> rdf:content or something.
> 
> Where this falls short, I think, is in ease-of-hand-authoring and in
> not allowing bnodes to be shared between the graphs.  But a lot of
> people don't want that anyway and may be happy to discourage it like
> this.  Also, it's not as easy to process as n-quads, especially
> for massive dumps, and some mechanism would need to be introduced for
> signaling the default graph.  (Something like "<> eg:defaultGraph
> <g1>.")
> 
> (Note re [2], Ivan, these are literals just like xs:integer, and don't
> open up any new issues.  There's no more need for them to be subjects
> than for integers to be subjects.  The value space is g-snaps, the
> lexical space for the turtle one is the set of turtle g-texts, etc.)
> 
>     -- Sandro
> 
> [1] http://www.w3.org/2000/10/swap/doc/Reach.html
> [2] http://lists.w3.org/Archives/Public/public-rdf-wg/2011Feb/0127
> 
> 
> 
>

Received on Friday, 4 March 2011 17:34:08 UTC