W3C

List of comments on “Linked Data Platform 1.0” (dated 11 March 2014)

Quick access to

There are 16 comments (sorted by their types, and the section they are about).

question comments

Comment LC-2929
Commenter: Joe Ross <joeross@us.ibm.com> (archived message)
Context: 4.2.4.4 If an otherwise valid HTTP PUT request is received...
assigned to John Arwe
Resolution status:

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2930
Commenter: Joe Ross <joeross@us.ibm.com> (archived message)
Context: 4.3.1.3 The representation of an LDP-RS MAY have an rdf:typ...
assigned to John Arwe
Resolution status:

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2932
Commenter: Joe Ross <joeross@us.ibm.com> (archived message)
Context: 4.3.2.1 LDP servers MUST provide a text/turtle representation of the requested LDP-RS [turtle].
assigned to John Arwe
Resolution status:

Shouldn't this say something like "... MUST provide a text/turtle
representation of the requested LDP-RS, unless otherwise specified via the Accept Header"?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2935
Commenter: Joe Ross <joeross@us.ibm.com> (archived message)
Context: 5.2.8 HTTP OPTIONS
assigned to John Arwe
Resolution status:

This doesn't seem to have anything to do with HTTP OPTIONS. Why is
it a subsection under HTTP OPTIONS?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

general comment comments

Comment LC-2931
Commenter: Joe Ross <joeross@us.ibm.com> (archived message)
Context: 4.3.1.14 LDP clients SHOULD be capable of processing succes...
assigned to Arnaud Le Hors
Resolution status:

This seems like a good statement to make, and it should not be at
risk.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2933
Commenter: Joe Ross <joeross@us.ibm.com> (archived message)
Context: 5.2.3.2 When a successful HTTP POST request to an LDPC resu...
assigned to John Arwe
Resolution status:

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2936
Commenter: Joe Ross <joeross@us.ibm.com> (archived message)
Context: 7.2 Preferences on the Prefer Request Header
assigned to John Arwe
Resolution status:

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)".
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-2915: Null relative URIs
Commenter: Reto Gmür <reto@apache.org> (archived message)
Context: 5.2.3.7 In RDF representations, LDP servers MUST interpret...
Not assigned
Resolution status:

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
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

editorial comments

Comment LC-2925
Commenter: Martin Nally <nally@us.ibm.com> (archived message)
Context: in
assigned to Steve Speicher
Resolution status:

it would be quite useful to have more examples. Developers will really heavily on them for comprehension, perhaps even more that the normative text.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2923
Commenter: Martin Nally <nally@us.ibm.com> (archived message)
Context: Membership triples
assigned to Steve Speicher
Resolution status:

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2926
Commenter: Joe Ross <joeross@us.ibm.com> (archived message)
Context: 4.2.1.4 LDP servers exposing LDPRs MUST advertise their LDP...
assigned to John Arwe
Resolution status:

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."
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2927
Commenter: Joe Ross <joeross@us.ibm.com> (archived message)
Context: 4.2.1.6 LDP servers MUST publish any constraints on LDP cli...
assigned to John Arwe
Resolution status:

An example would be useful here...
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2928
Commenter: Joe Ross <joeross@us.ibm.com> (archived message)
Context: 4.2.4.3 If an otherwise valid HTTP PUT request is received...
assigned to John Arwe
Resolution status:

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2924
Commenter: Martin Nally <nally@us.ibm.com> (archived message)
Context: 5.1 Introduction This section is non-normative. Many HTTP a...
assigned to Steve Speicher
Resolution status:

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2914: Named Graphs
Commenter: Reto Gmür <reto@apache.org> (archived message)
Context: 5.1 Introduction
Not assigned
Resolution status:

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
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2934
Commenter: Joe Ross <joeross@us.ibm.com> (archived message)
Context: 5.2.8.1 When an LDPC server creates an LDP-NR (for example,...
assigned to John Arwe
Resolution status:

There is an indication of additional HTTP OPTIONS requirements for LDPC,
but none seem to be described.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: Overview.php,v 1.46 2013-10-04 08:11:33 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org