Re: Multiple Named Graph

On 26 Mar 2014, at 22:32, Reto Gmür <reto@apache.org> 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 whose state is fully represented in RDF, corresponding to an RDF named graph. See also the term RDF Source from [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. 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). 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. 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. 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

So this is particularly relevant for LDPCs in my view, as these may want to do what atom does and show some of the content of the ldp:contain_ed elements.
So say you have an LDPC at <http://an.example/> . You do a GET on it requesting Turtle and you receive

<> a ldp:BasicContainer;
     ldp:contains <a>, <b>, <c> .

If a GET on <http://an.example/a>  returns

 <> a foaf:PersonalProfileDocument;
    foaf:primaryTopic <#i> .
 <#i> foaf:firstName "Reto" ;
       foaf:knows <b>, <c> .

then a GET in format text/n3 on <http://an.example/> could, in order to help the client know something about what is being discussed in <a>, <b> or <c> return
a part or the whole of the graph like this.

@prefix log: <http://www.w3.org/2000/10/swap/log#>.
#see http://www.w3.org/2000/10/swap/doc/CwmBuiltins
<> a ldp:BasicContainer;
     ldp:contains <a>, <b>, <c> .

<a> log:includes { <#i> foaf:firstName "Reto"; foaf:knows <b>, <c> . }
<b> log:includes { <#i> foaf:firstName "Henry" }
<c> log:includes { <#i> foaf:firstName "Arnaud" }

An LDPC does not usually want to allow content of those graphs to leak into the LDPC itself. For example leaking the foaf:knows relation
would not allow one to tell which of <a>, <b> and <c> contained that statement .

An LDPC which is as I see a statement made by the server about the contents of the resources
it is taking care of, can also make metadata statements about the resources without quoting them.
Those would be statements such as
  - creation time
  - owner
  - title
Those tend to  correspond to the atom elements. They usually relate a resource to a literal. ( Note that 
a named graph is just such a literal since you can always have an equivalent "..."^^lang:Turtle string.  


> 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

No, it just returns the named graph, but without the name ( no need for the name, the client allready knows it since it did a GET on it ).
So above it would return for the LDPC <http://an.example/>

<> a ldp:BasicContainer;
     ldp:contains <a>, <b>, <c> .

In other words the server returns the default graph when a request for Turtle is made.

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

It does. In Turtle only the default graph is returned.


> The novel precaching mechanism is only suggested for graphs, not for other resources (e.g. using multipart/mime).

yes. The reason this is suggested is that people wanted something like Atom's content element, and it was important to
explain that this could be achieved using named graphs.

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

Social Web Architect
http://bblfish.net/