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

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.

>>> 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”?

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

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

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

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

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

Received on Wednesday, 15 May 2013 16:48:55 UTC