- From: Henry Story <henry.story@bblfish.net>
- Date: Thu, 16 May 2013 16:48:40 +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 16 May 2013, at 12:01, Richard Cyganiak <richard@cyganiak.de> wrote:
> Henry,
>
> The problem with the blank node approach is this. As you point out, it never makes a graph wrong to simply replace a URI with a blank node. It just omits some detail. RDF Semantics guarantee that. But. The reverse holds as well. It's not wrong for a client to undo your omission and substitute the URI back in, instead of the blank node, if the client knows for whatever reason the right URI (through a sameAs statement for example). RDF Semantics guarantee that too. Now if a client does this, and the semantics say that it can, then the information which members are inlined and which not is lost, in your proposal. So LDP would have to say that clients must not do that. This would contradict RDF Semantics. Essentially, the result would e that if clients use too high a level of OWL reasoning, then the protocol would break.
But that is also very true of the ldp:memberInlined. Different levels of reasoning might well increase the number of relations
on a member, or might merge information from one member to the next member. If the content of those members is contradictory then
you have a big problem. I pointed this out below. So your argument on reasoning is also an argument against ldp:memberInlined.
Do you agree with that? How do we sort out that problem?
>
> Therefore, let's express the distinction the way information is expressed in RDF: in triples. (Or HTTP headers. Just not in a blank node vs URI distinction.)
>
> Richard
>
>
> On 15 May 2013, at 23:17, Henry Story <henry.story@bblfish.net> wrote:
>
>>
>> On 15 May 2013, at 23:27, Richard Cyganiak <richard@cyganiak.de> wrote:
>>
>>> On 15 May 2013, at 19:41, Henry Story <henry.story@bblfish.net> wrote:
>>>>>> [[
>>>>>> 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?
>>>>
>>>> The IRI denotes a resource whose representation is equivalent to the containing element.
>>>> The element need to be XML btw: it can be html, text, RDF or any other representation
>>>> for that matter. If you don't like that relation then it is easy to create a new one
>>>> that is more appropriate for us.
>>>
>>> A relation - it would probably have to be a new one - with the semantics “fetch this URL to get a complete description of the subject” would address the use case, I think. It shouldn't matter whether the subject is blank though.
>>>
>>>>> 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.
>>>>
>>>> Behaviorally it is equivalent.
>>>
>>> No. Your proposal provides a distinction between “can be dereferenced” and “cannot be dereferenced”. That's not the distinction that's being asked for here. The relevant distinction here is: “server has provided everything it knows” versus “server has a URL where more information about the resource can be fetched”. These are completely different things.
>>
>> Good then lets define and use that relation.
>>
>>>
>>>> You cannot retrieve the resource, so that is all you can know about the resource.
>>>
>>> As I've said before, this statement is not true, because there can be many ways, including but not limited to sameAs, of inferring that the blank node is in fact a placeholder for some URI in the graph.
>>
>> If you bring reasoning in then you have other serious problems with ldp:memberInlined. Namely how can you guarantee
>> that the inlined members of two different resources don't interact in odd ways through reasoning too?
>>
>> <> rdf:member <m1>, <m2>;
>> ldp:memberInlined <m1>, <m2> .
>>
>> <m1> buying <jaguar> .
>> <m2> buying <jaguar> .
>>
>> <jaguar> price [ euros 20000 ]
>>
>> Now does both <m1> and <m2> have to contain the same price?
>>
>> I am sure one could concoct thousands of other examples. Some of these inferences might
>> only be visible to reasoners at one level of owl, others at other stronger levels of owl.
>> Does the spec not have to now deal with all these levels of reasoning?
>>
>> This does seem to make the case for limiting the type of relations on a LDPR to only metadata relations,
>> that is relations on an information resource which Erik Wilde has argued for in the past. But if you
>> do that then the case for using blank nodes can be made even better.
Please consider the above.
>>>
>>>> What is the Use Case you are trying to solve anyway? Perhaps that would help to be clear about it.
>>>
>>> The use case is efficiency. If complete descriptions are inlined, clients would waste time and bandwidth by resolving member URIs. For example, think of an LDP server that manages an RDF vocabulary (with slash namespace). The server would probably present the entire vocabulary as a single RDF document with complete inline descriptions, as is customary for vocabularies. Does a generic LDP client that wants to retrieve the entire thing need to do 1 request or n+1 (where n is the number of terms in the vocabulary)?
>>
>> what you really need is to express things in N3 with named graphs.
>> By restricting ourselves to Turtle or other simple RDF formats, we can get the
>> same thing by using RDF literals.
>>
>> <> rdf:member [ :title "An Order for a sanwich" ;
>> :updated "2013-05-13..."^^xsd:dateTime;
>> :content """
>> @base ...
>> @prefix ...
>>
>> <> :title "An Order for a Sandwich";
>> :primaryTopic _:x
>> _:x a TunaSandwich
>> """^^lang:Turtle
>> ]
>>
>> Here you'd know exactly what the content was, and you can use the updated relation
>> to see if you need to update the resource.
>>
>> If people had spent more time earlier standardising N3 we'd certainly have a more
>> elegant solution. Perhaps this will spur those efforts.
>>
>>
>>>
>>>> Do
>>>> we have a use case of inlined membership in the UCR ? http://www.w3.org/TR/ldp-ucr/
>>>
>>> Good question.
>>
>> Thanks.
>>
>>>
>>>>>> 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.
>>>>
>>>> You are splitting hairs here.
>>>
>>> No, Henry, I am educating you so that you can speak on the topic more authoritatively.
>>
>> Stop being pretentious please, it does not help us solve our problems.
>>
>>>
>>> All the best,
>>> Richard
>>>
>>>
>>>>
>>>>>
>>>>>> 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.
>>>>
>>>> Is that relevant to this use case?
>>>>
>>>>>
>>>>> 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/
>>>>
>>>> Social Web Architect
>>>> http://bblfish.net/
>>>>
>>>>
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>>
Social Web Architect
http://bblfish.net/
Received on Thursday, 16 May 2013 14:49:16 UTC