Re: RDF named graph use case and requirement

On Thu, 2011-09-22 at 07:09 +0100, Graham Klyne wrote:
> On 21/09/2011 23:27, Sandro Hawke wrote:
> > [cc'ing public-prov-wg, but reply-to set to public-rdf-prov, where as I
> > understand it this discussion should proceed.]
> >
> > On Wed, 2011-09-21 at 16:49 +0100, Graham Klyne wrote:
> >> (I've also posted this summary at
> >> http://www.w3.org/2011/prov/wiki/ProvenanceRDFNamedGraph#Requirement_from_discussion_with_Andy_Seaborne)
> >>
> >> In a meeting with Andy Seaborne this morning, we discussed provenance
> >> requirements and RDF named graphs, in light of some options that the RDF group
> >
> > ( quiet grumble about the use of the undefinable term "named graph"... )
> 
> Agree the term is not always hepful.  Do we have a better commonly-known term 
> for such discussions?
> 
> >> might be considering.
> >>
> >> The resulting requirement that we articulated was that for the purposes of
> >> provenance, we must be able to treat two "named" graphs with identical graph
> >> content as two distinct entities.
> >>
> >> ...
> >>
> >> The use-case is this:
> >>
> >> Suppose we have some resource R.
> >>
> >> Observer A makes a provenance assertion about R on Monday 2011-09-19, which is
> >> expressed as an RDF graph Pra
> >>
> >> Observer B makes a provenance assertion about R on Friday 2011-09-23, expressed
> >> as RDF graph Prb
> >>
> >> To express provenance about the provenance assertions, we may wish to say:
> >>
> >> Pra statedBy A; onDate "2011-09-19" .
> >>
> >> Prb statedBy B; onDate "2011-09-23" .
> >>
> >> It may be that the provenance assertions Pra and Prb have identical content;
> >> i.e. they are RDFG graphs containing identical triple sets.  For the purposes of
> >> provenance recording, it is important that even when they express the same
> >> graphs, Pra and Prb are distinct RDF nodes.  If Pra and Prb are treated as a
> >> common RDF node, one might then infer:
> >>
> >> _:something statedBy A ; onDate "2011-09-23" .
> >>
> >> which in this scenario would be false.
> >
> > Isn't this just some modeling confusion?  Pra and Prb are each an event
> > of the authoring of a statement (ie they are "statings"), not
> > statements, based on how you use them, giving them dates and such.
> > Those two statings can then be connected to the same statement (graph,
> > G1).
> >
> > Pra statement G1; dc:creator A; dc:date "2011-09-19".
> > Prb statement G1; dc:creator B; dc:date "2011-09-23".
> >
> > Then G1 can just be a literal, or whatever we use to allow conversations
> > about g-snaps.
> 
> Yes, this is indeed a modelling choice.  As I note later, I wasn't dismissing 
> the graph literal approach, just trying be expose the need, which might be 
> addressed in different ways.

At the risk of belaboring the point, I think this is just a modeling
error.   If one were going to make Pra be a literal, it would have to be
a Stating literal, not a Statement (Graph) literal.  This would be a
weird thing to make a literal, but if you did, I suppose it would
include not just what was stated (the Statement part) but also who
stated it and when.   Then, of course, Pra and Prb would not be equal,
and you wouldn't need the other arcs.  Really, it would just be bizarre.

As for the original question of graph literals, this week I'm leaning
toward just using strings.  It seems more reusable and robust:

    :Bob :claims [
       :body "@prefix rdf: <....";
       :contentType "text/turtle"
    ];

... but it is pretty low-level and I guess after working with it for a
while, I'd crave something like N3.

     -- Sandro 

> >
> >> .....
> >>
> >> A particular consequence of this is that an RDF "named graph" specification
> >> based on graph literals (where RDF literals are self-denoting), somewhat like
> >> formulae in Notation 3, would have to be used with care.  That is, if Pra and
> >> Prb are graph literals, then Pra = Prb, and the given provenance-of-provenance
> >> statements could not be expressed as suggested above.
> >
> > It seems to me Pra and Prb are not g-snaps (RDF graphs), so there's no
> > problem here.
> 
> Again, an interaction of modelling and design choices.  There *could* be a 
> problem, depending on what choices are made.
> 
> #g
> --
> 
> >> (This does not preclude a graph literal approach being used, but the above
> >> use-case might need to be constructed slightly differently.)
> >>
> >> #g
> >> --
> >>
> >>
> >
> >
>

Received on Thursday, 22 September 2011 12:39:31 UTC