W3C home > Mailing lists > Public > public-ldp@w3.org > January 2014

Re: Multiple resource representations during LDPC POST (5.4.1)

From: (wrong string) čius <martynas@graphity.org>
Date: Sun, 5 Jan 2014 00:38:37 +0200
Message-ID: <CAE35VmzbOMcE-RBuDCYxxRZSjdQnSU9J-pX3Qb9DtcxaetzMHQ@mail.gmail.com>
To: John Arwe <johnarwe@us.ibm.com>
Cc: "public-ldp@w3.org" <public-ldp@w3.org>
Hey John,

thanks for your email -- and sorry for the late reply.

I'm glad that you mention a graph store, because I think it helps to
illustrate the problem.

If LDP would only store and retrieve graphs, how would its purpose be
different from the GSP? But LDP aims to work with "resource
representations" instead.

Lets say a triplestore (or rather quad store) is used as LDP backend,
and each such "resource representation" is stored in a separate newly
minted named graph. If would issue 2 following requests with 2

  POST /docs

  <http://external.org> a foaf:Document .

  POST /docs

  <http://external.org> a sioc:Site .

that would result in 2 separate named graphs. GSP could be used to
retrieve the contents of them separately.

Many applications however are using triplestores via SPARQL endpoints,
and use DESCRIBE queries to retrieve resource representations. With
the graph contents as above, DESCRIBE <http://external.org> is likely
to return a multi-graph representation:

  <http://external.org> a foaf:Document ;
    a sioc:Site .

What I want to point out is that resource representations and graphs
are different dimensions of Linked Data. An LDP scenario that I think
makes most sense would be:
- GET resource representations generated by SPARQL DESCRIBE (possibly
from multiple graphs)
- POST/PUT/DELETE graphs as the GSP does

That would make the LDP read-write life-cycle somewhat asymmetrical,
but I don't see why that's a problem.

In my opinion, the current LDP spec fails to differentiate between
resource representations and graphs, or conflates the terms to
(over)simplify the design.


On Wed, Dec 18, 2013 at 9:39 PM, John Arwe <johnarwe@us.ibm.com> wrote:
> You describe the expected result correctly.
> It is not "typical", insofar as not all triples in the response's
> representation (in this case, zero) have the HTTP URI as subject.
> That does not cause any compliance problem.  "Typical" is going to be
> somewhat in the eye of the beholder anyway, pretty much always.  A "simple"
> graph store might just assign a random HTTP URI that matches zero subject
> URIs _in every case_.  For it, "typical" is the mismatch case.
> The fact that the difference exists at all is the interesting point.  I've
> seen a lot of implementers coming from an OO background think that these LDP
> resources are just "objects", the HTTP URL is their "object handle", and
> therefore [Shirley it must be true that] every triple's subject must be the
> HTTP URI (after all, it's one of *that object's* properties!).  Signalling
> that there *is* a difference, that leads to a conversation like this one, is
> the point of the text.  The companion documents should be where most of the
> "discussion" happens; the spec here is just noting a consequence of the
> underlying specs, not adding anything new.  9.3.1 (written long after the
> "typically" came into being) addresses this more head-on - would a link to
> 9.3.1 help?
> Best Regards, John
> Voice US 845-435-9470  BluePages
> Tivoli OSLC Lead - Show me the Scenario
Received on Saturday, 4 January 2014 22:39:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:03:11 UTC