- From: Steve Speicher <sspeiche@gmail.com>
- Date: Tue, 14 May 2013 17:07:37 -0400
- 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: <CAOUJ7JoMUosbACwg6DZWQGiuQx4jMHrdXVi4heWrS9jZyf=QCA@mail.gmail.com>
On Mon, May 13, 2013 at 12:25 PM, 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.
>
Thinking about this a little more, I don't think it really makes it
simpler. If fact, it makes the simplest case harder, typical case harder,
inlined case better in some ways but introduces ambiguity into what the
resource URI is. Let me try to explain....
> 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
>
This is not true, they do NOT need to know about these new relations. They
only need to know about these IF they care if the member resource (MR) has
been fully inlined. I have and can think of many cases where I don't
really need to know this.
> 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 )
>
To be clear, a client only needs to do this if its primary use case is
optimizing fetching of complete MRs. If the client does not care about
them being inlined or optimizing, it would just ignore the additional
triples.
> 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.
>
As stating the simplest scenario, where I have a client that doesn't care
about inlining...it now needs to be concerned with blank nodes and
interpreting owl:sameAs and/or atom:self. owl:sameAs is where the
ambiguity comes in, if my MR already has multiple statements saying it is
owl:sameAs <foo>, <bar>, <taco>, ... then which one is the member of the
container? I know you would say "they all are, since they are the same".
This adds complexity to a simple client, I think we could all agree.
There are cases for my simple client where it can get by just fine with
partial information to drive a number of use cases: driving a selection
box, understanding the kinds of resources, etc.
<> a ldp:Container;
rdfs:member <bug1>, <bug2>.
<bug1> a bugs:Bug;
dcterms:title "Server crashes hard";
owl:sameAs <http://jira.apache.org/issue-14>.
<bug2> a bugs:Bug:
dcterms:title "Button not aligned";
Now if server decides that it wants to provide a the <bug1> MR inlined, it
would have to change to:
<> a ldp:Container;
rdfs:member <bug2>,
[ a bugs:Bug;
dcterms:title "Server crashes hard";
:state "Completed";
owl:sameAs <http://jira.apache.org/issue-14>, <bug1>. ].
<bug2> a bugs:Bug:
dcterms:title "Button not aligned";
>From this example, it seems like an extreme shift from simply doing (Option
B):
<> a ldp:Container;
rdfs:member <bug1>, <bug2>;
ldp:memberInlined <bug1>.
<bug1> a bugs:Bug;
dcterms:title "Server crashes hard";
:state "Completed";
owl:sameAs <http://jira.apache.org/issue-14>.
<bug2> a bugs:Bug:
dcterms:title "Button not aligned";
To me, inserting the extra statements that can be ignored by simple clients
seems have the most advantages.
>
> 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.
>
>
I'm not sure it is that simple with your approach and agree with the goals
you state. I believe the approach I illustrated, meets those goals as well.
- Steve
> 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 Tuesday, 14 May 2013 21:08:06 UTC