Re: New Proposal (6.1) for GRAPHS

On Wed, 2012-03-28 at 16:35 +0200, Ivan Herman wrote:
> On Mar 28, 2012, at 16:25 , Sandro Hawke wrote:
> 
> > On Wed, 2012-03-28 at 10:10 -0400, Peter F. Patel-Schneider wrote:
> >> Wow!
> >> 
> >> The graph semantics includes quite a bit of new stuff:
> > 
> > I am, of course, leaving defining the formal semantics to people who are
> > actually good at that stuff.   I'm just trying to convey they idea with
> > some formal-ish language and some test cases.
> > 
> >> owl:sameAs as equality
> > 
> > That's just used to express test cases.
> > 
> >> functional relationships
> >> partially reflexive relationships
> > 
> > Those exist....  Is it odd to define a relationship and say, in the
> > specification, that it is functional?    rdf/rdfs define lots of
> > relations; a few of them like rdf:first and rdf:rest perhaps should have
> > been defined as functional.  (Of course, that would have snuck equality
> > reasoning into RDF, which I guess is why it didn't happen.   Maybe
> > that's a problem with rdf:hasGraph?)
> > 
> >> The special status of the rdf:Graph class is rather unusual.
> >> 
> >> The proposal leaves open just what an RDF graph is in the semantics.  Is it 
> >> just a graph (so that its syntax matters), or is it a set of interpretations 
> >> (so that what matters is its RDF meaning)?
> > 
> > Your terms confuse me a little.  I mean rdf:Graph to be the class of RDF
> > Graphs, that is, every instance of rdf:Graph is a mathematical set of
> > (s,p,o) triples, where s is a node with an optional IRI label, etc.
> 
> 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?

    -- 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
> 
> 
> 
> 
>

Received on Monday, 2 April 2012 15:04:20 UTC