There are 16 comments (sorted by their types, and the section they are about).
question comments
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...
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to John Arwe
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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.
Related issues: (space separated ids)
WG Notes:
Resolution: This sentence was changed to the following:
The representation of a LDP-RS MAY have an rdf:type of ldp:RDFSource for Linked Data Platform RDF Source. (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].
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to John Arwe
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Shouldn't this say something like "... MUST provide a text/turtle
representation of the requested LDP-RS, unless otherwise specified via the Accept Header"?
Related issues: (space separated ids)
WG Notes:
Resolution: This is a requirement for servers to offer Turtle and in no way is meant to say that content negotiation does not apply.
Hopefully, the addition about JSON-LD makes this more obvious:
LDP servers SHOULD provide a application/ld+json representation of the requested LDP-RS [JSON-LD].
(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
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to John Arwe
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :This doesn't seem to have anything to do with HTTP OPTIONS. Why is
it a subsection under HTTP OPTIONS?
Related issues: (space separated ids)
WG Notes:
Resolution: This paragraph is there because it is a requirement for responding to options requests. We could add "when responding to OPTIONS requests on the LDP-NR's request-URI" or similar, but the OPTIONS part of that is really covered by the preceding paragraph.
(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...
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Arnaud Le Hors
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :This seems like a good statement to make, and it should not be at
risk.
Related issues: (space separated ids)
WG Notes:
Resolution: It is the intent of the WG to incorporate this into the spec eventually but the final decision will be made at the end of CR. This feedback will be taken into account then.
(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...
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to John Arwe
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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.
Related issues: (space separated ids)
WG Notes:
Resolution: This is indeed why the WG added the possibility for clients to express a preference using the Prefer header.
(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
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to John Arwe
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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)".
Related issues: (space separated ids)
WG Notes:
Resolution: This is correct.
(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...
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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
Related issues: (space separated ids)
WG Notes:
Resolution: Although the WG understands your concerns, having weighed the pros and cons, the WG decided to stick with the current null-relative design, and add a non-normative explanation of how that works, how to do it in some tools, etc, in a footnote, appendix, or (hopefully) Best Practices and Guidelines document.
See http://www.w3.org/2013/meeting/ldp/2014-04-15#resolution_1 (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
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Steve Speicher
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :it would be quite useful to have more examples. Developers will really heavily on them for comprehension, perhaps even more that the normative text.
Related issues: (space separated ids)
WG Notes:
Resolution: Agreed.
(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
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Steve Speicher
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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.
Related issues: (space separated ids)
WG Notes:
Resolution: Agreed. The definition has been changed not to imply any particular way the triples are stored. (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...
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to John Arwe
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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."
Related issues: (space separated ids)
WG Notes:
Resolution: Agreed. (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...
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to John Arwe
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :An example would be useful here...
Related issues: (space separated ids)
WG Notes:
Resolution: Agreed. (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...
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to John Arwe
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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.
Related issues: (space separated ids)
WG Notes:
Resolution: Agreed that it might seem to conflict but the following note clarifies the intent:
Non-normative note: Clients might provide properties equivalent to those already in the resource's state, e.g. as part of a GET/update representation/PUT sequence, and those PUT requests are intended to work as long as the server-controlled properties are identical on the GET response and the subsequent PUT request. (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...
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Steve Speicher
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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.
Related issues: (space separated ids)
WG Notes:
Resolution: It is always difficult to find the right balance between providing enough examples for people to understand the spec and not crowding the specification with non-normative content. As it's become common practice the WG is developing a Primer that is dedicated to educating people on the spec. The editor's draft is at: http://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html
(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
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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
Related issues: (space separated ids)
WG Notes:
Resolution: The WG decided to remove references to named graphs by removing "named" in terminology section, removing paragraph in examples, and removing sentence in section 5.2.3.4 and 5.2.4.2
See http://www.w3.org/2013/meeting/ldp/2014-04-15#resolution_3
(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,...
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to John Arwe
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :There is an indication of additional HTTP OPTIONS requirements for LDPC,
but none seem to be described.
Related issues: (space separated ids)
WG Notes:
Resolution: The additional requirement to HTTP is merely to support OPTIONS. This is true on all LDPRs. (Please make sure the resolution is adapted for public consumption)
Add a comment .