- From: Henry Story <henry.story@bblfish.net>
- Date: Sat, 18 May 2013 21:40:52 +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 18 May 2013, at 19:28, Richard Cyganiak <richard@cyganiak.de> wrote:
>
>
> On 18 May 2013, at 17:00, Henry Story <henry.story@bblfish.net> wrote:
>
>>
>> On 18 May 2013, at 17:28, Richard Cyganiak <richard@cyganiak.de> wrote:
>>
>>> On 18 May 2013, at 11:37, Henry Story <henry.story@bblfish.net> wrote:
>>>>> The problem with your proposal was that a server that serves consistent data and a client that does correct reasoning can end up with a wrong result regarding whether members are inlined or not.
>>>>
>>>> And how is that a problem? All that will happen is that he will fetch the same data again remotely. Compared to the danger that inlining itself represents (see below) this seems harmless.
>>>
>>> This can increase response times for a simple operation like "fetch me a copy of the complete FOAF ontology" by a factor of 100, moving it from "pretty much instantaneously" to "let me get a cup of coffee while this finishes".
>>>
>>> That's the whole reason why the ability to inline is such an important optimisation.
>>
>> but your problem may just simply be that you are using the LDPC to do work it should not be doing.
>> why do you want to put all the work into the LDPC? If you publish an ontology you can put it into one file
>> for example.
>
> I want to be able to PATCH and DELETE individual members, but still have a (possibly paged) view of the entire thing to make the by far most common operation GET efficient.
You can have paged views of LDPRs.
>
>>>>> I might not understand the problem you tried to illustrate with your jaguar example. It looks like the server provides some additional information in the inlined data that a client wouldn't get when dereferencing the individual members: the fact that both price entities are the same. This seems harmless to me.
>>>>
>>>> Yes, and what if different content were contradictory? It is so easy to imagine situations like this:
>>>> take a collection of relations where different points of views are expressed about a murder scene.
>>>
>>> They can decide not to inline. It's the server's decision whether to inline or not.
>>>
>>> They can also offer a TriG variant via content negotiation and inline for clients that support TriG. All the various property-based proposals for inlining are forward compatible and allow that.
>>
>> Good so if people want to use trig, or better N3 then create a relation called content than
>> relates a member to its quoted content.
>>
>> <> rdf:member <member> .
>> <member> content { <member#thing> a FunThing; funlink <quirky> } .
>
> I mentioned TriG as a way of addressing your hypothetical murder mystery scenario. It's not what people want.
Atom is very popular and widely used: it does exactly that: it distinguises the content of each entry.
All I know of what "people" want is what the UC&R tells us we are mean to produce.
>
>>
>>>
>>>> Clearly I hope you don't suppose that all these witnesses to the murder will be in complete agreement
>>>> with each other from the get go. Not all links from one content to another need to be a link that suggests
>>>> that merging the two sets of data is a good idea. This is something I don't get the feeling the Linked Data
>>>> community has thought through carefully.
>>>>
>>>> The notion of inlining seems to me either:
>>>>
>>>> 1. Extreemly likely to mislead developers implementing LDP, who could way too easily end up creating inconsistent graphs.
>>>
>>> If you assume that implementers have the expertise to correctly keep separate viewpoints in separate graphs in the first place, then surely they will be able to understand that they shouldn't merge these graphs by inlining.
>>
>> Most people understand seperate viewpoints much better than they do the consequences of
>> merging viewpoints. Plus this is a web application where many different clients could be
>> interacting with a container.
>
> That all depends on the use case. I happen to have a use case where the server needs to enforce application-specific consistency between members anyway.
My argument is that you can do the same with an LDPR.
Since you can do what you need to do with an existing resource, and since we don't have time to work on this
forever I suggest you use the simplest existing procedures.
>
>> The Atom Protocol allows people to publish content very
>> well and without trouble because it makes sure that people don't have to deal with these
>> problems.
>
> Remember that inlining is optional. Servers can decide not to do it, clients can decide to ignore it and fetch all members anyway, nothing breaks.
>
>> You are pushing the bar very high by ignoring this.
>
> Nonsense.
Sorry but "setting the bar very high" is not nonsense. The problems are numerous:
- in order to be consistent a client POSTing to an LDPR needs to know the full content of
all the members, to make sure it is not creating contradictions. This is easy with simple
metadata relations from a member because one knows there that one can post anything and
it will remain consistent if the one believes the content to be true. If one also needs
to think of all the content of all the other memebers one has a very different task.
- With paging one may not know all the content of all the pages, and these may change over time.
- You are confusing document creation ( LDPC create new GETable resources) with talking about objects
these documetns talk about. The examples in the sepc are all moving into HTTP range-14 space, by confusing
those. It's better to steer clear of that debate if we want this spec to succeed.
>
>> Furthermore you'll require people to have a full view of an LDPC which could contain a lot of
>> elements. They'd need to know that it is not contradicting any of the content in all of members.
>
> Inlining erases provenance. Don't do it if your members have different provenance and you want to keep that provenance represented. Making that decision doesn't require full knowledge of what's contained in a container. It just requires knowing what your application is.
If you do that why not use an LDPR?
>
>> Is the client meant to know that? How is the client meant to know POSTing to a LDPC will inline
>> things?
>
> By looking at the membersInlined flag?
Good so why not just PATCH an LDPR?
That would simplify the spec, and we could finish this first version, and it would be very flexible.
>
>> If POSTing to an LDPC will inline things why don't you just PATCH an LDPR instead of using
>> an LDPC?
>
> That's a side effect, and not the reason why I need inlining. The reason is efficiency of GET while still being able to manipulate members separately.
You can manupulate parts of graphs seperately by PATCHing them.
>
>>
>>>
>>>> There needs to be text in the spec warning people about the types of data that can be inlined, and of the consequences of inlining.
>>>> The safest type of data one can put on a member in an LDPC are the type of metadata relations used in Atom and Dublin Core.
>>>> Most other types of relation I think are a bad idea for attaching to members in an ldpc.
>>>
>>> I happen to disagree. I plan to use LDP with SKOS concept schemes and RDFS vocabularies, and inlining entire schemes/ontologies in a single document (while still being able to manipulate them independently via HTTP) will be rather helpful.
>>
>> But you could manipulate the LDPRs that are not LDPCs with PATCH/PUT/GET etc....
>
> Doing a GET on each member is too slow.
So create one LDPR that you can work with by PATCHing it.
>
>> You don't need to do everything with LDPCs. I think the problem here is that
>> you and many others here think LDPCs are the only tool in the shed.
>
> Speak for yourself Henry. I don't think that LDPCs are the only tool in the shed,
Well I think we should be working from the UC&Rs we have. You seem to be going
way beyond the UC&R. Show me a UC&R that absolutely requires your inlining.
My position is that you can PATCH LDPRs wherever you are arguing for inlining inside
of LDPCs.
>
>>
>>>
>>>> 2. Secondly if you publish just metadata on an LDPR then the content will hopefully be something extra, And then it is
>>>> quite simple: either the LDPC publishes the quoted content for an LDPR in which case there is no need to fetch the original,
>>>> or the quoted content is not published in which case one should go and fetch the LDPR.
>>>
>>> I'm not familiar with you notion of "quoted content".
>>
>> So you did not read my previous mails carefully then.
>> For example here http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0091.html
>>
>> <> 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
>> ] .
>
> This is pretty useless as the payload is opaque to parsers/validators/query engines.
That's what Atom does. It's not complicated, it's only a bit ugly because we don't have
N3 or Trig.
>
>> As pointed out above and in other threads with N3 you could quote those in { } which would be a lot clearer.
>>
>> <> rdf:member <member> .
>> <member> :title "An Order for a sanwich" ;
>> :updated "2013-05-13..."^^xsd:dateTime;
>> :content {
>> <member> :title "An Order for a Sandwich";
>> :primaryTopic [ a TunaSandwich ]
>>
>> } .
>>
>>
>> So here it is simple to work out when something is inlined: check the :content
>> relation, if it exists you have the content right there and then.
>
> This is much more complicated than just having the triples in the same graph. Let's keep simple things simple.
IT's not simple because when you inline you have to deal with owl reasoning and possible inconsistency over
large number of contents that no client has a full overview of.
So let's keep things simple: PATCH LDPRs when you want something like inlining. Then it is clear
when you need to take consistency into account.
LDPCs are for creating new document resources. You then patch LDPRs when you want consistent graphs.
You can create new resources in an LDPR by using # urls.
>
>>
>>
>>>
>>>> 3. an LDPC in the end should be something a default apache server could put together, with no special tweaking.
>>>> It should be something that works out of the box.
>>>
>>> I fully agree.
>>
>> Good. The problem is that inlining content without quotation is spurring people to do the wrong
>> thing.
>
> In many use cases it spurs them to do exactly the right thing.
For that they can PATCH LDPRs just as well. PATCHing an LDPR makes it clear
that you are doing an operation that requires the result to be logically consistent.
>
>
>>
>>>
>>>> As it is the spec is turning into something that only owl reasoning
>>>> specialists could put together without messing it up.
>>>
>>> There's nothing at all in the property-based inline proposals that cannot be done on plain Apache or even with static files.
>>>
>>> I want to make sure that LDP still works as expected even if you are one of these rare people who rely on advanced features of OWL. This does not mean that every LDP user needs to know anything about OWL!
>>
>> I want to know what the use cases we have that require you to do this inlining.
>
> I gave you my use case earlier: manipulate RDFS and SKOS via LDP.
So create a LDPR and then PATCH it when you want to create a larger consistent LDPR.
Then paging can be used if you feel it is too big.
>
>> That is why I opened
>> Issue-70. http://www.w3.org/2012/ldp/track/issues/70
>>
>> If you want to be efficient you can just publish the content as a quotation or as a graph.
>
> That is not how one publishes RDFS and SKOS files.
It solves the efficiency problem of LDPCs that you argued was the key reason to have it.
If you want consistency your LDPRs that are not LDPCs.
So in neither case do you need inlining.
>
> Richard
>
>>
>>>
>>> Richard
>>>
>>>
>>>
>>>>
>>>> That is why the real problem for this group has to be: could the use cases people have been putting
>>>> forward be solved without putting so much weight on LDPCs. I am for very simple LDPCs that act
>>>> simply like directories and then for an additional vocabulary to help explain what the consequences
>>>> of POSTing to an LDPC are, independent of the functionality of the LDPC itself. This would help
>>>> distinguish data the server is an charge of (metadata), and what the meaning of POSTing information
>>>> in an LDPC is going to be.
>>>>
>>>> Henry
>>>>
>>>>
>>>>>
>>>>> Richard
>>>>>
>>>>>>
>>>>>>>
>>>>>>> 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/
>>>>
>>>> Social Web Architect
>>>> http://bblfish.net/
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>>
Social Web Architect
http://bblfish.net/
Received on Saturday, 18 May 2013 19:41:27 UTC