Re: Multiple Named Graph

On Tue, Apr 1, 2014 at 12:26 AM, Sandro Hawke <sandro@w3.org> wrote:

>  On 03/26/2014 05:32 PM, Reto Gmür wrote:
>
>
>
>
> On Wed, Mar 26, 2014 at 12:29 PM, henry.story@bblfish.net <
> henry.story@bblfish.net> wrote:
>
>>
>>  On 26 Mar 2014, at 10:50, Reto Gmür <reto@apache.org> wrote:
>>
>>
>>
>>
>> On Tue, Mar 25, 2014 at 10:21 PM, henry.story@bblfish.net <
>> henry.story@bblfish.net> wrote:
>>
>>>
>>>  On 25 Mar 2014, at 14:59, Reto Gmür <reto@apache.org> wrote:
>>>
>>>
>>> On Tue, Mar 25, 2014 at 2:30 PM, henry.story@bblfish.net <
>>> henry.story@bblfish.net> wrote:
>>>
>>>>  So to start from the beginnging again.
>>>> I checked the mentions of "named graph" in the spec.
>>>>
>>>>  In the definitions section:
>>>> [[
>>>> Linked Data Platform RDF Source (LDP-RS) An LDPR<https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#dfn-linked-data-platform-resource> whose
>>>> state is fully represented in RDF, corresponding to an RDF named graph<http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph>.
>>>> See also the term RDF Source<http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-source> from
>>>> [rdf11-concepts<https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#bib-rdf11-concepts>
>>>> ].
>>>> ]]
>>>>
>>>>  Section 5.1:
>>>> [[
>>>> Alternatively, servers may provide the net worth resource and
>>>> supporting containers in a single response representations. When doing
>>>> this, a preference would be for RDF formats that support multiple
>>>> named graphs
>>>>
>>>
>>>  If as you quote above, the state of an LDPR is fully represented in
>>> RDF why should the preference be to return a format that support multiple
>>> named graphs? The latter suggest the resource can be more completely
>>> represented using more than just RDF which contradicts the first.
>>>
>>>
>>  If a client were to ask for text/n3 then you could give more context
>> back. You would not be returning more information about the graph itself,
>> you
>> would just be adding more information about the context of other graphs,
>> presumably graphs referred to by the graph that was requested. So there is
>> no contradiction here.
>>
>
>  So to make sure I understand: an LDP-RS is fully represented by an RDF
> graph.
>
>
> Yes.
>
>
>   The URI of the LDP-RS together with the RDF graph that represent the
> resource form a named graph according to the definition for RDF datasets in
> RDF 1.1 (a pair of graph name and a graph).
>
>
> True, but irrelevant.
>
>
>   So rather than returning a graph and LDP server might also return a
> dataset consisting of a single named graph with the URI of the requested
> resource as graph name.
>
>
> No, I don't think it's allowed to do that.
>
>
>   LDP defines (implicitly somewhere) a relationship between the graph
> name and the graph (the graph describes the resource identified by graph
> name) and allows returning the dataset instead of the graph.
>
>
> Yeah, that's hinted at by the example.   I'm starting to think we should
> take out all mention of named graphs and leave that for a future spec that
> defines a mechanism by which clients can ask servers to give them a dataset
> (eg a BasicContainer and all its members as named graphs).
>
>
>   Furthermore for precaching purposes (and extending the current REST
> architecture) it suggests that the dataset returned might also contain
> other graphs which are not part of the representation of the requested
> resource but which are presumably "referred to by the graph that was
> requested" meaning that the graph name is a node in the graph that
> represents the requested resource.
>
>
> Yes, I think something like that would be useful, but there's not much
> point in hinting at it without specifying it.
>
>
>    Furthermore, if the client didn't request a format that encodes a
> dataset but just wants a graph the LDP server returns the union of all the
> named graphs in the dataset
>
>
> I sure hope not.    Whenever a client does a GET on a Dataset resource
> using a non-dataset syntax, the RDF 1.1 specs say just the default graph
> should be sent.
>
>
>    - unfortunately the client in this case is not able to identify the
> subgraph that fully represents the LDP-RS, that's why the preference would
> be the RDF formats that support multiple named graphs. The novel precaching
> mechanism is only suggested for graphs, not for other resources (e.g. using
> multipart/mime).
>
>
> or just HTTP/2.0, yeah.
>
> So, would you be happy with us just taking out all the mentions of named
> graphs in the spec?   I think that's just an editorial change, since we
> don't actually say anything formal about them.
>

Yes, that would be good. I think both the example suggesting to return a
dataset as well at the mention of named graphs in the definitions are
confusing. An RDF Datasource is what it is.

Cheers,
Reto


>
>       -- Sandro
>
>
>   Am I getting it right?
>
>  Reto
>
>
>>
>>
>>
>>>  I don't agree. You can represent graphs by using datatypes that map
>>> strings to graphs. For example one could invent one such as
>>> rdf:Turtle .
>>>
>>>
>>>  :joe :believes "<http://jane.org/#me> <http://relationship.vocab/loves>
>>> <http://joe.org/#i> ."^^rdf:Turtle .
>>>
>>>  RDF semantics allows this to be done. It would allow you to encode
>>> graphs in simple RDF formats. Don't forget that
>>> in the RDF semantics a datatype is a function from a string to an
>>> object. The ones defined by xsd are numbers, binary, date.
>>> Nothing stops you from having maps from rdf syntaxes to the graphs they
>>> represent.
>>>
>>>   Yes. But it change nothing to the contradiction above.
>>
>>
>>>
>>>  It would help to understand your positions if you could state your
>>> take on Sandro's statements/questions.
>>>
>>>   It still would.
>>
>>  Reto
>>
>>
>>        Social Web Architect
>> http://bblfish.net/
>>
>>
>
>