Disposition of comments for the Linked Data Platform (LDP) Working Group

Hi,


More than one year has passed since Pierre-Antoine Champin explained why
specifying LDP using the concept of "null relative URI" is problematic
[1]. Unfortunately the concept of "null relative URI" is still in the
latest version of the spec. This ties the LDP spec to some RDF
serializations and probably violates RFC3986 according to which the
*sender* is responsible for making sure that a base URI for the relative
references can be established.

But the main point that LDP is no longer defined in terms of the abstract
RDF syntax shows to be problematic when using higher level abstraction
frameworks such as JAX-RS (the java standard for REST) to implement and
LDP server or client.

A method that returns an RDF representation of a Resource would typically
be defined like this:

@GET
public Graph getResourceDescription();

The JAX-RS runtime (more specifically so called MessageBodyWriters) will
take care of serializing the returned graph into the format preferred by
the client.

One would define a method that handles post requests with an RDF Graph as
message body like this:

@POST
public Response postResourceDescritption(Graph graph);

Unfortunately this doesn't work to handle LDP POST requests as the message
body cannot be converted to an RDF Graph until some application logic
defined the URI for the new resource. All work around are quite horrible.
One would be to have a type RelativeGraph to which text/turtle can be
deserialized without a base URI, another one would be to take a String as
argument and take care of the deserialization in the application code.


Pierre-Antoine original solution proposal included the usage of BNodes. As
some people have strong feelings against BNodes this elegant approach
might have been precociously discarded by some.

A quick fix would be to simply define "null relative URI" (which is
currently undefined both in LDP as well as in RFC 3986/3987) as
http://www.w3.org/ns/ldp/null-relative/.


Cheers,
Reto



1. http://lists.w3.org/Archives/Public/public-ldp-wg/2013Mar/0077.html

There is an indication of additional HTTP OPTIONS requirements for LDPC,
but none seem to be described.

Since an LDPR can be an LDP-NR, and the header must be included
responses to HTTP requests for all LDPRs, the following statement seems incorrect:
"The presence of this header asserts that the server complies with the LDP specification's constraints on HTTP interactions with LDPRs, that is it asserts that the resource has Etags, has an RDF representation, and so on, which is not true of all Web resources served as RDF media types."

An example would be useful here...

Server-managed properties are non-modifiable, and these can be
ignored, so this seems to contradict 4.2.4.1. Perhaps this needs to be
qualified to exclude ignored server-managed properties.

Does the PUT succeed in performing an update in this case? Should all requests with 4xx responses be assumed as having failed? Seems that it would be more consistent if info was returned using describedBy link header as mentioned previously for constraint violations.

I don't understand this statement. "... MAY have an rdf:type of
only one of ldp:RDFSource ..." . Seems there is something wrong with this sentence.

This seems like a good statement to make, and it should not be at
risk.

Shouldn't this say something like "... MUST provide a text/turtle
representation of the requested LDP-RS, unless otherwise specified via the Accept Header"?

It appears that there is no requirement that ldp:contains be
included in responses to GET requests, which is good, since in our case
that would result in doubling the size of the container resource, and
doesn't provide any useful information to clients.

This doesn't seem to have anything to do with HTTP OPTIONS. Why is
it a subsection under HTTP OPTIONS?

Prefer header and return=representation
I assume that the default representation could omit the containment
triples, unless they are explicitly requested using Prefer header. That would avoid having to double the size of LDPC representations for legacy clients.
There is a statement below example 11 that seems to say this: "A server that honors this hint would return (at least) the following response, and perhaps only this (it might well omit containment triples if they are not specifically requested)".

Definition of "membership triples" seems limiting in saying LDP-RS'
state must hold the membership triples. In our implementation, the
membership triple is held in a graph assigned to the member resource.
Suggestion is to adjust the definition to allow for this perhaps common
implementation case.

Confusing examples (3-5) [2], there needs to be a bit more description
between these. It would be helpful to add some narrative between them, as well as showing POST example.

it would be quite useful to have more examples. Developers will really heavily on them for comprehension, perhaps even more that the normative text.

Hello,

I've notice that the latest published version suggest using RDF formats
that support multiple named graphs. For the net-worth example it suggests
using "one named graph for the net worth resource and then two others for
asset and liability containers".

I am irritated by this recommendation. First the specification mandates
the possibility to serialize as turtle which does not currently support
multiple named graphs.

But more importantly I don't see the reason of this splitting of the
information into many graphs and it seems to significantly restrict the
possibilities to implement LDP Servers.

The suggested three graph do not seem to represent three different
information sources with thus potentially contradictory statements. So in
this situation there is typically no quotation-use case with provenance
that must be preserved. Grouping into different graphs what can be safely
expressed in one graph seems to deny the expressive power of RDF and
suggesting that the grouping of triples into different graphs has a
significance beyond provenance.

With the previous published version it was possible to have an LDP
compliant server backed by a single graph. This would be my choice of
implementation if the data has a single provenance and the access
restrictions are the same for all the triples. This change in the new
version seems however to mandate implementation to be based on different
graphs for the different resources.

In my opinion this is a significant loss of flexibility. I would like for
simple implementations based on one graph to be possible. It can also be
useful for an implementation to be based on multiple graphs representing
different provenances or confidentiality but containing descriptions of
larger and possibly overlapping sets of resources. With the latter
approach the resource description accessed through LDP would contain more
or less triples depending on my access rights and the sources I've decided
to trust.

Cheers,
Reto