- From: Sandro Hawke <sandro@w3.org>
- Date: Mon, 31 Mar 2014 18:26:22 -0400
- To: Reto Gmür <reto@apache.org>, "henry.story@bblfish.net" <henry.story@bblfish.net>
- CC: Linked Data Platform WG <public-ldp-wg@w3.org>, public-ldp <public-ldp@w3.org>
- Message-ID: <5339EB8E.1050603@w3.org>
On 03/26/2014 05:32 PM, Reto Gmür wrote:
>
>
>
> On Wed, Mar 26, 2014 at 12:29 PM, henry.story@bblfish.net
> <mailto:henry.story@bblfish.net> <henry.story@bblfish.net
> <mailto:henry.story@bblfish.net>> wrote:
>
>
> On 26 Mar 2014, at 10:50, Reto Gmür <reto@apache.org
> <mailto:reto@apache.org>> wrote:
>
>>
>>
>>
>> On Tue, Mar 25, 2014 at 10:21 PM, henry.story@bblfish.net
>> <mailto:henry.story@bblfish.net> <henry.story@bblfish.net
>> <mailto:henry.story@bblfish.net>> wrote:
>>
>>
>> On 25 Mar 2014, at 14:59, Reto Gmür <reto@apache.org
>> <mailto:reto@apache.org>> wrote:
>>
>>>
>>> On Tue, Mar 25, 2014 at 2:30 PM, henry.story@bblfish.net
>>> <mailto:henry.story@bblfish.net> <henry.story@bblfish.net
>>> <mailto: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.
-- 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/
>
>
Received on Monday, 31 March 2014 22:26:32 UTC