- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Wed, 15 May 2013 17:48:30 +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>
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