W3C home > Mailing lists > Public > public-rdf-wg@w3.org > April 2012

Re: New Proposal (6.1) for GRAPHS

From: Sandro Hawke <sandro@w3.org>
Date: Mon, 02 Apr 2012 11:52:17 -0400
To: Ivan Herman <ivan@w3.org>
Cc: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, public-rdf-wg <public-rdf-wg@w3.org>
Message-ID: <1333381937.28199.45.camel@waldron>
On Mon, 2012-04-02 at 17:19 +0200, Ivan Herman wrote:
> On Apr 2, 2012, at 17:04 , Sandro Hawke wrote:
> 
> > On Wed, 2012-03-28 at 16:35 +0200, Ivan Herman wrote:
> [skip]
> >> 
> >> Hm. We get to the same issue as with the properties. Within the RDF world, we only have blank nodes, URIrefs, and literals. If you want to talk about rdf:Graph as a class in the RDF sense the way you describe, then either (a) a graph should be defined in terms of a blank node, URIRef or a literal or (b) we have to extend the notion of 'things' that can be in RDF.
> > 
> > I don't really understand.
> > 
> > Allow me to fall back on computer programming terminology, please, since
> > that's where I'm most comfortable.
> > 
> > If I implement an RDF parser, triplestore, an serializer, with 2004 RDF,
> > in an object oriented programming style, then yes, I probably am going
> > to have classes for BlankNode, LabeledNode (aka URIRef), and Literal.
> > 
> > I think you're saying you're concerned that with proposal 6.1 folks will
> > have to also implement some kind of Graph class in their code.
> > 
> > But don't they need something like that if they're going to handle
> > multiple graphs, eg with TriG or SPARQL with named graphs?  Right now,
> > doesn't that code have some kind of Graph class now?  Well, it probably
> > either has a Graph -- a set of triples -- or it uses quads with the
> > fourth column being a graph id -- identifying some kind of Graph object.
> > 
> > Am I in the right space here?    Can you explain your concern like this,
> > in terms of code changes people might have to make?
> 
> Yes, you are the right space. What you say is that graphs are different then what constitute an RDF triple today.
> 
> What this means is that, if we go the road you refer to, we will have to extend the RDF concepts, the RDF Semantics, and of course all the various other documents, to have a new type of RDF, where the constituents of a triple may be BlankNode, LabeledNode, Literal, and Graph. I guess this can be done, but it requires a significant amount of work, it has consequences in a number of different specs, like OWL, RIF, SPARQL, etc.

That's not what I'm trying to say.  If it is somehow a consequence of
what I'm saying, I don't see how.   I don't see any reason any code
would have to be changed, unless that code already deals with some kind
of graph naming syntax or protocol.

Systems that want to read or write TriG, yes, they'll need to have some
notion of Graphs, but I think they already do.   They'll probably need
to change a bit to align with the standard, but that's just natural
because they're often doing things a little different from each other
right now.

> As for implementations: today, an implementation probably has the notion of a triple, which may have s,p,o, which can be of class... well, you know that. Those classes, including all the code that rely on those classes, will have to be extended to allow for a 4th type of thing, otherwise they may throw exceptions, go wrong, blow up, etc. I am not sure I can foresee all the consequences.
> 
> (I know a bit RDFLib from inside. It does have the notion of a Graph, of course, which can even have an associated label. But all the code that, say, retrieves triples from a graph store rely on the fact that any resource has to be Literal, URIRef, or BNode, to use the RDFLib terminology. Those methods are not necessarily prepared for the possibility of having a Graph at places.)

No, in this plan, normal RDF is unchanged.   Just because the object of
a triple can *semantically* refer to an RDF Graph does not mean the RDF
Abstract Syntax has to be extended to help it do so.   The object of a
triple can *semantically* refer to a person, but there's no special node
type in the RDF Abstract Syntax to support that -- people have to be
identified by URIRef and/or BNodes.   RDF Graphs, as I imagine it, are
like that, too.   In Plain-Old-RDF (as found in RDF/XML, Turtle, the
default graph of a TriG document, or any of the named graphs in a TriG
document) the Graphs are referred by URIRefs or BNodes.

Maybe there's a use case we can talk through, even implement in Python,
to make this more clear....    Maybe "keeping inferred triples
separate", or some version of the endorsement case, or some provenance
example?

    -- Sandro

> And... what does it buy us? There is nothing that forces us to go down that route. The type of a Graph 'label' can be defined outside of the formal RDF Semantics and concepts, and things work just as well (I know Pat will shoot me down, though:-)
> 
> Ivan
> 
> > 
> >    -- Sandro
> > 
> >> Personally, I would keep away from that: I am not sure we can do it in time, I am not sure it is consensus ready for a standard. The labels in a (l,G) pair are URI refs (or BNodes), ie, they can be typed to any RDF graphs; but I think the exact semantics of what that means should be defined _outside_ of the formal RDF semantics (essentially in English prose).
> >> 
> >> Maybe RDF 2.0 can provide a mathematically precise semantics. Maybe we can publish a note for the direction such a recommendation might take. But I am not sure we can go beyond that.
> >> 
> >> (Yes, I may be in my pessimistic mood.)
> >> 
> >> Ivan
> >> 
> >> 
> >> 
> >>> 
> >>>  -- Sandro
> >>>> 
> >>>> peter
> >>>> 
> >>>> 
> >>>> On 03/27/2012 10:23 PM, Sandro Hawke wrote:
> >>>>> I've written up design 6 (originally suggested by Andy) in more
> >>>>> detail.  I've called in 6.1 since I've change/added a few details that
> >>>>> Andy might not agree with.  Eric has started writing up how the use
> >>>>> cases are addressed by this proposal.
> >>>>> 
> >>>>> This proposal addresses all 15 of our old open issues concerning graphs.
> >>>>> (I'm sure it will have its own issues, though.)
> >>>>> 
> >>>>> The basic idea is to use trig syntax, and to support the different
> >>>>> desired relationships between labels and their graphs via class
> >>>>> information on the labels.  In particular, according to this proposal,
> >>>>> in this trig document:
> >>>>> 
> >>>>>   <u1>  {<a>  <b>  <c>  }
> >>>>> 
> >>>>> ... we only know that<u1>  is some kind of label for the RDF Graph<a>
> >>>>> <b>  <c>, like today.  However, in his trig document:
> >>>>> 
> >>>>>   {<u2>  a rdf:Graph }
> >>>>>   <u2>  {<a>  <b>  <c>  }
> >>>>> 
> >>>>> we know that<u2>  is an rdf:Graph and, what's more, we know that<u2>
> >>>>> actually is the RDF Graph {<a>  <b>  <c>  }.  That is, in this case, we
> >>>>> know that URL "u2" is a name we can use in RDF to refer to that g-snap.
> >>>>> 
> >>>>> Details are here: http://www.w3.org/2011/rdf-wg/wiki/Graphs_Design_6.1
> >>>>> 
> >>>>> That page includes answers to all the current GRAPHS issues, including
> >>>>> ISSUE-5, ISSUE-14, etc.
> >>>>> 
> >>>>> Eric has started going through Why Graphs and adding the examples as
> >>>>> addressed by Proposal 6.1:
> >>>>> http://www.w3.org/2011/rdf-wg/wiki/Why_Graphs_6.1
> >>>>> 
> >>>>>     -- Sandro (with Eric nearby)
> >>>>> 
> >>>>> 
> >>>> 
> >>> 
> >>> 
> >>> 
> >> 
> >> 
> >> ----
> >> Ivan Herman, W3C Semantic Web Activity Lead
> >> Home: http://www.w3.org/People/Ivan/
> >> mobile: +31-641044153
> >> FOAF: http://www.ivan-herman.net/foaf.rdf
> >> 
> >> 
> >> 
> >> 
> >> 
> > 
> > 
> 
> 
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> FOAF: http://www.ivan-herman.net/foaf.rdf
> 
> 
> 
> 
> 
Received on Monday, 2 April 2012 15:52:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:03 UTC