- From: Henry Story <henry.story@bblfish.net>
- Date: Wed, 15 May 2013 16:50:29 +0200
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: Arnaud Le Hors <lehors@us.ibm.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
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.
>
>> 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
>
>>> 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
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? The RDF semantic sepc says that replacing a URI with a bnode is equivalent. ( less info, but the
truth value does not change). 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.
>
> 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 14:51:03 UTC