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

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

> I don't like this. You are overloading the semantics of rdfs:member, owl:sameAs and atom:self.

I only suggested owl:sameAs as a teaser.
I am currently -1 on all forms of ldp:membersInlined.

> rdfs:member doesn't mean “download this ASAP”.

I did not say it was. But when you have a relation to a different resource, that resource
is always definitive, so the behavior is 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.

Furthermore I do not agree that we are changing the semantics of anything.
In RDF you can always replace a URI with a blank node without affecting
the truth value of the graph. 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/

Received on Wednesday, 15 May 2013 09:31:06 UTC