- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Wed, 15 May 2013 10:10:10 +0100
- To: Henry Story <henry.story@bblfish.net>
- Cc: Arnaud Le Hors <lehors@us.ibm.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-Id: <1C60616E-CAB1-4FE1-B4C1-603C76711FFF@cyganiak.de>
I don't like this. You are overloading the semantics of rdfs:member, owl:sameAs and atom:self. rdfs:member doesn't mean “download this ASAP”. 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.
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/
>
Received on Wednesday, 15 May 2013 09:10:37 UTC