Re: ISSUE-58: the simple solution to inlined membership

On 15 May 2013, at 18:48, Richard Cyganiak <richard@cyganiak.de> wrote:

> 
> 
> On 15 May 2013, at 15:50, Henry Story <henry.story@bblfish.net> wrote:
> 
>> 
>> On 15 May 2013, at 13:41, Richard Cyganiak <richard@cyganiak.de> wrote:
>> 
>>> 
>>> 
>>> On 15 May 2013, at 10:30, Henry Story <henry.story@bblfish.net> wrote:
>>>>> rdfs:member doesn't mean “download this ASAP”.
>>>> 
>>>> I did not say it was.
>>> 
>>> I read your proposal as saying that it does.
>>> 
>>> If it doesn't, then how does a client know whether the in-lined description is complete or not?
>> 
>> If there is no URI then the client cannot directly fetch the information. So it must be inlined.
>> That follows from how blank nodes work.
> 
> That doesn't follow at all. You can have a blank node and a sameAs triple pointing to a URI with additional information about the described entity. The use of a blank node does not mean that there's nothing else to know/fetch about the entity.

That is why I said the owl:sameAs was just a teaser. Clearly it is not the right relation.

> 
>>>> But when you have a relation to a different resource, that resource
>>>> is always definitive, so the behavior is correct linked data.
>>> 
>>> I don't understand this sentence.
>> 
>> the definitive resource for knowing the meaning of foaf:knows is the document you GET when 
>> you fetch http://xmlns.com/foaf/0.1/knows (after the 303 redirect). For TimBerners Lee's WebID 
>> 
>>  http://www.w3.org/People/Berners-Lee/card#i"
>> 
>> The defintive document - the document that gives its definition is
>> 
>> http://www.w3.org/People/Berners-Lee/card
>> 
>> This is shown in details here:
>> 
>> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html#overview 
> 
> Ok, this is what you mean by “definitive”. But what did you mean by “the behavior” and “correct linked data”?

if you have 

 <> rdf:member <member> .
 <member> :title "hello" .

then finding out more about <member> by dereferencing it is the right thing for a client to do.
If it behaves that way then one should not be surprised. <member> is the resource that says what member
is. This is the same as if I you tell me "The red chair you bought yesterday is in the kitchen". Your
saying that is made true or false by the red chair being or not being in the kitchen.


> 
>> 
>>> 
>>>>> atom:self doesn't mean “you may download this but you have a complete representation already”. So either you are saying that LDP should change the semantics of these properties, or you are not actually offering a solution.
>>>> 
>>>> I am saying the ldp:membersInlined is offering an answer to a problem that
>>>> can be solved without much better. Furthermore it even allows us to have something
>>>> that would make Atom be just a syntactical variation on LDP, which is not an 
>>>> inconsiderable advantage.
>>> 
>>> Atom has no way of indicating whether entries are in-lined or not, so I don't see how it helps solving the issue.
>> 
>> They are all inlined. Entries with atom:self indicate thereby their location. 
>> The precise definition is this:
>> 
>> [[
>> 3.  The value "self" signifies that the IRI in the value of the href
>>      attribute identifies a resource equivalent to the containing
>>      element.
>> ]]
>> 
>>  http://tools.ietf.org/html/rfc4287#section-4.2.7.2
> 
> Does this imply that the IRI denotes an XML element?

The IRI denotes a resource whose representation is equivalent to the containing element.
The element need to be XML btw: it can be html, text, RDF or any other representation
for that matter. If you don't like that relation then it is easy to create a new one
that is more appropriate for us. 


> 
>> which may not be exactly what we want - we need to discuss this with the Atom
>> sepciaists. But it is very close.
>> 
>>> 
>>>> Furthermore I do not agree that we are changing the semantics of anything.
>>> 
>>> If LDP says that clients can interpret the patterns you proposed as indicating whether the in-lined description is complete or not, then it has ascribed additional semantics to these properties.
>> 
>> How can it?
> 
> Nothing in RDF or in the definitions of said properties says anything about in-lining or completeness of descriptions. So if LDP says something about these things, without adding a new property or class or HTTP header, then surely it has added something to the semantics of RDF or of these properties.

Behaviorally it is equivalent. You cannot retrieve the resource, so that is all you can know about the resource.

What is the Use Case you are trying to solve anyway? Perhaps that would help to be clear about it. Do
we have a use case of inlined membership in the UCR ? http://www.w3.org/TR/ldp-ucr/ 

> 
>> The RDF semantic sepc says that replacing a URI with  a bnode is equivalent. ( less info, but the 
>> truth value does not change).
> 
> This is incorrect, as I said earlier. Entailment is not equivalence.

You are splitting hairs here.

> 
>> In RDF stands for Resource Description Framework. You can relate things to resources
>> by name, by description,  or both ( as many examples in the current spec show ).
>> 
>>> 
>>>> In RDF you can always replace a URI with a blank node without affecting
>>>> the truth value of the graph.
>>> 
>>> (Nitpick: not true, as it can turn a false graph into a true one.)
>> 
>> ?? In the RDF Semantics simple entailment Rules section we have the following entailment rule
>> 
>> se2: uuu aaa xxx => _:nnn aaa xxx .
>> 
>> http://www.w3.org/TR/rdf-mt/#simpleRules
>> 
>> An entailment by definition does not change a truth into a falsehood.
> 
> But an entailment may change a falsehood into a truth. So it may change the truth value from false to true. Entailment is not equivalence. You already know this. I just pointed out that you spoke sloppily.

Is that relevant to this use case?

> 
> Richard
> 
> 
> 
>> 
>>> 
>>> Richard
>>> 
>>> 
>>>> The current spec is therfore consistent with
>>>> the proposal.
>>>> 
>>>> 
>>>>> 
>>>>> Richard
>>>>> 
>>>>> 
>>>>> On 13 May 2013, at 17:25, Henry Story <henry.story@bblfish.net> wrote:
>>>>> 
>>>>>> Hi, 
>>>>>> 
>>>>>>     During today's teleconference discussing this issue I suddenly 
>>>>>> realised that there is a  futher solution to those presented here, which 
>>>>>> I think is both simpler and can be applied much more widely: that is to 
>>>>>> all linked data.
>>>>>> 
>>>>>> So first of all it turns out that there are good arguments for the use cases
>>>>>> of A and B/C . The current proposals end up requiring the creation of two
>>>>>> new relations. This is problematic because linked data consumers need to
>>>>>> know about these relations. That is a Linked Data Client instead of just having
>>>>>> to make the following query on an LDPC named ldpc
>>>>>> 
>>>>>>  val members =  ldpc/rdf.member
>>>>>> 
>>>>>> It now has to also do something like the following
>>>>>> 
>>>>>> val members = if ( (ldpc/membersInlined).contains("true") )  
>>>>>>                             ldpc/ldp.memberInlined
>>>>>>                        else {
>>>>>>                            val local = ldpc/ldp.memberInlined 
>>>>>>                            val remote = (ldpc/rdf.member - local).map( _.follow )
>>>>>>                            local union remote
>>>>>>                         }
>>>>>> 
>>>>>> ( much more complex that this to tell you the truth )
>>>>>> 
>>>>>> What is problematic about this is that it would only work for LDPCs, and one could
>>>>>> easily imagine that each LDP service would develop its own version making code
>>>>>> unecessarily difficult.
>>>>>> 
>>>>>> But I have to explain the simple solution to make it clear why I can use "unecessarily 
>>>>>> difficult": the simple answer is that RDF already comes with the tools to make distinguish
>>>>>> nodes one can follow and nodes one cannot: the blank node! So I propose that for resources
>>>>>> where all the data is contained locally you do the following
>>>>>> 
>>>>>> <> a ldp:Container;
>>>>>>  rdf:member [ atom:title "Atom Robots Run Amock" ;
>>>>>>                        atom:summary "Atom Robots having drunk a triple espresso semantic powerade....";
>>>>>>                        atom:content " ...." ; 
>>>>>>                        atom:id "http://news.example/2013/05/13/atomRobots"^^xsd:anyURI;
>>>>>>                        atom:updated "2013-05-13..."^^xsd:dateTime;
>>>>>>                      ],
>>>>>>                      [ atom:title "Semantic Revolution in the Blogosphere";
>>>>>>                        atom:summary "it all makes sense!";
>>>>>>                        atom:id "http://news.example/2013/05/12/semanticRevolution"^^xsd:anyURI;
>>>>>>                        ...
>>>>>>                      ] .
>>>>>> 
>>>>>> So here it is no way to follow the LDPC members, and the ids are not URIs in use
>>>>>> either. If you do want to also allow people to follow the links you can use owl:sameAs or perhaps
>>>>>> the rel=self relation from atom
>>>>>> 
>>>>>> <> a ldp:Container;
>>>>>>  rdf:member [ atom:title "Atom Robots Run Amock" ;
>>>>>>                        atom:summary "Atom Robots having drunk a triple espresso semantic powerade....";
>>>>>>                        atom:content " ...." ; 
>>>>>>                        atom:self <atomRobots>;
>>>>>>                        atom:updated "2013-05-13..."^^xsd:dateTime;
>>>>>>                      ],
>>>>>>                      [ atom:title "Semantic Revolution in the Blogosphere";
>>>>>>                        atom:summary "it all makes sense!";
>>>>>>                        atom:self <semanticRevolution>;
>>>>>>                        ...
>>>>>>                      ] .
>>>>>> 
>>>>>> 
>>>>>> Finally for members where the data should be followed first rather than later
>>>>>> 
>>>>>> <> a ldp:Container;
>>>>>>  rdf:member <atomRobots>,  <semanticRevolution> .
>>>>>> 
>>>>>> # a bit of extra data for people arriving on this resource using simpler tools...
>>>>>> 
>>>>>> <atomRobots> atom:title "Atom Robots Run Amock" ;
>>>>>>                        atom:summary "Atom Robots having drunk a triple espresso semantic powerade....";
>>>>>>                        atom:updated "2013-05-13..."^^xsd:dateTime .
>>>>>> 
>>>>>> <semanticRevolution> atom:title "Semantic Revolution in the Blogosphere";
>>>>>>                        atom:summary "it all makes sense!" .
>>>>>> 
>>>>>> The advantage of this is that one can write clients that follow links automatically ( with 
>>>>>> cleverly built cashes to avoid fetching ontologies such as foaf or DC of course ) 
>>>>>> so that as far as possible they always  go to the source of the data, where the information
>>>>>> is defined. When a server does not wish this to happen the server can simply use the blank
>>>>>> node thereby simply stopping the possiblity of getting further information!  The atom:self type
>>>>>> relation or owl:sameAs then gives a way for the server to express that all the data is available
>>>>>> remotely at that location.  
>>>>>> 
>>>>>> This way we have an answer that works for all LDP resources and we can write generic
>>>>>> code without having to make special corner cases for each type of resource we come across.
>>>>>> 
>>>>>> 
>>>>>> Henry
>>>>>> 
>>>>>> On 30 Apr 2013, at 20:51, Arnaud Le Hors <lehors@us.ibm.com> wrote:
>>>>>> 
>>>>>>> Looking back at what has been said on this issue, I see several possible paths forward: 
>>>>>>> 
>>>>>>> Option A: Richard's original proposal (without all the details): 
>>>>>>> 
>>>>>>> Add to ldp:Container a boolean property which, when true, indicates that a complete description of all the members is inlined in the container document. 
>>>>>>> 
>>>>>>> Option B: 
>>>>>>> 
>>>>>>> Add to ldp:Container a property ldp:memberInlined which indicates the members for which a complete description is inlined in the container document. 
>>>>>>> 
>>>>>>> Option C: 
>>>>>>> 
>>>>>>> Add a boolean property ldp:memberInlined which, when true, indicates that a complete description of that member is inlined in the container document. 
>>>>>>> 
>>>>>>> Option D: 
>>>>>>> 
>>>>>>> Add a repeatable HTTP Header, such as X-Cacheable-for, which when set to a member URI means that a complete description of that member is inlined in the container document. 
>>>>>>> 
>>>>>>> 
>>>>>>> Here are some examples for each options: 
>>>>>>> 
>>>>>>> Option A: 
>>>>>>> 
>>>>>>> # The following is the representation of
>>>>>>> #                  http://example.org/netWorth/nw1
>>>>>>> @prefix dcterms: <http://purl.org/dc/terms/>.
>>>>>>> @prefix ldp:      <http://www.w3.org/ns/ldp#>.
>>>>>>> @prefix o:       <http://example.org/ontology/>.
>>>>>>> 
>>>>>>> <>
>>>>>>> a o:NetWorth, ldp:Container;
>>>>>>> ldp:membershipPredicate o:asset;
>>>>>>> o:asset <a1>, <a2>; 
>>>>>>>  ldp:membersInlined true.
>>>>>>> 
>>>>>>> <a1>
>>>>>>>  a o:Stock;
>>>>>>>  o:value 10000.
>>>>>>> <a2>
>>>>>>>  a o:Bond;
>>>>>>>  o:value 20000. 
>>>>>>> 
>>>>>>> 
>>>>>>> Option B: 
>>>>>>> 
>>>>>>> # The following is the representation of
>>>>>>> #                  http://example.org/netWorth/nw1
>>>>>>> @prefix dcterms: <http://purl.org/dc/terms/>.
>>>>>>> @prefix ldp:      <http://www.w3.org/ns/ldp#>.
>>>>>>> @prefix o:       <http://example.org/ontology/>.
>>>>>>> 
>>>>>>> <>
>>>>>>> a o:NetWorth, ldp:Container;
>>>>>>> ldp:membershipPredicate o:asset;
>>>>>>> o:asset <a1>, <a2>; 
>>>>>>>  ldp:memberInlined <a1>, <a2>.
>>>>>>> 
>>>>>>> <a1>
>>>>>>>  a o:Stock;
>>>>>>>  o:value 10000.
>>>>>>> <a2>
>>>>>>>  a o:Bond;
>>>>>>>  o:value 20000. 
>>>>>>> 
>>>>>>> Option C: 
>>>>>>> 
>>>>>>> # The following is the representation of
>>>>>>> #                  http://example.org/netWorth/nw1
>>>>>>> @prefix dcterms: <http://purl.org/dc/terms/>.
>>>>>>> @prefix ldp:      <http://www.w3.org/ns/ldp#>.
>>>>>>> @prefix o:       <http://example.org/ontology/>.
>>>>>>> 
>>>>>>> <>
>>>>>>> a o:NetWorth, ldp:Container;
>>>>>>> ldp:membershipPredicate o:asset;
>>>>>>> o:asset <a1>, <a2>.
>>>>>>> 
>>>>>>> <a1>
>>>>>>>  a o:Stock;
>>>>>>>  o:value 10000; 
>>>>>>>  ldp:memberInlined true.
>>>>>>> <a2>
>>>>>>>  a o:Bond;
>>>>>>>  o:value 20000; 
>>>>>>>  ldp:memberInlined true. 
>>>>>>> 
>>>>>>> Option D: 
>>>>>>> 
>>>>>>> # The following is the representation of
>>>>>>> #                  http://example.org/netWorth/nw1
>>>>>>> @prefix dcterms: <http://purl.org/dc/terms/>.
>>>>>>> @prefix ldp:      <http://www.w3.org/ns/ldp#>.
>>>>>>> @prefix o:       <http://example.org/ontology/>.
>>>>>>> 
>>>>>>> <>
>>>>>>> a o:NetWorth, ldp:Container;
>>>>>>> ldp:membershipPredicate o:asset;
>>>>>>> o:asset <a1>, <a2>.
>>>>>>> 
>>>>>>> <a1>
>>>>>>>  a o:Stock;
>>>>>>>  o:value 10000.
>>>>>>> <a2>
>>>>>>>  a o:Bond;
>>>>>>>  o:value 20000. 
>>>>>>> 
>>>>>>> HTTP Headers: 
>>>>>>> X-Cacheable-for: http://example.org/netWorth/nw1/a1 
>>>>>>> X-Cacheable-for: http://example.org/netWorth/nw1/a2 
>>>>>>> 
>>>>>>> Comments anyone? 
>>>>>>> --
>>>>>>> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
>>>>>> 
>>>>>> Social Web Architect
>>>>>> http://bblfish.net/
>>>> 
>>>> Social Web Architect
>>>> http://bblfish.net/
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 

Social Web Architect
http://bblfish.net/

Received on Wednesday, 15 May 2013 18:41:48 UTC