Re: RDF named graph use case and requirement

On 22/09/2011 13:39, Sandro Hawke wrote:
>> 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.

It's only a modelling error if an application uses the RDF in an inappropriate 
way.  And whether it's a "stating literal" (whatever that may be), "statement 
literal" or something else is for the RDF group to figure out.

All I have been trying to say is that the choices made by the RDF group may have 
consequences for the way the resulting capability is used in the data models of 
applications.  My purpose was to highlight that some possible choices would have 
an effect on how application models might be constructed in RDF, and that we 
needed to be sure that whatever choice might be made there is a provenance 
requirement (as perceived by me) that it must be possible to address.  Isn't 
that why we're supposed to be talking?

Whatever choices the RDF group may make, there will be appropriate and 
inappropriate ways to use them.  To dismiss examples like mine as "modelling 
errors" is, in my view, to miss the point of having this coordination discussion 
at all.

Personally, I don't think it matters much what the RDF group decide on this 
matter:  I don't see any likely outcome that can't be used in some way to 
represent provenance appropriately.  (Some approaches might lead to marginally 
simpler models.)  But identifying requirement potential problem areas and using 
them to test the RDF proposals is probably still a good thing to do.

#g
--

>...   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 Friday, 23 September 2011 07:13:36 UTC