This document:Public document·View comments·Disposition of Comments·
Nearby:Linked Data Platform (LDP) Working Group Other specs in this tool
Status: allopen proposal pending resolved_yes resolved_no resolved_partial other Type: allsubstantive editorial typo question general comment undefined
Quick access to LC-2914 LC-2915 LC-2923 LC-2924 LC-2925 LC-2926 LC-2927 LC-2928 LC-2929 LC-2930 LC-2931 LC-2932 LC-2933 LC-2934 LC-2935 LC-2936
There are 16 comments (sorted by their types, and the section they are about).
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.
Shouldn't this say something like "... MUST provide a text/turtle representation of the requested LDP-RS, unless otherwise specified via the Accept Header"?
This doesn't seem to have anything to do with HTTP OPTIONS. Why is it a subsection under HTTP OPTIONS?
This seems like a good statement to make, and it should not be at risk.
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.
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)".
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
it would be quite useful to have more examples. Developers will really heavily on them for comprehension, perhaps even more that the normative text.
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.
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.
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.
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
There is an indication of additional HTTP OPTIONS requirements for LDPC, but none seem to be described.
Add a comment.