Re: Review and Comments for Linked Data Platform FPWD

David,

Apologies on the delay to getting through these comments, I had taken
a pass through them before and we even had a chance to discuss a
number of them both in person and on the list.  I figured I'd respond
directly here to try to close any loose ends.  The original email
thread spawned by David Wood is at [1].

Many thanks for the thorough review.

[1] - http://lists.w3.org/Archives/Public/public-ldp-wg/2012Oct/0259.html

Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> http://open-services.net

David Wood <david@3roundstones.com> wrote on 10/28/2012 06:23:10 AM:

> From: David Wood <david@3roundstones.com>
> To: public-ldp-wg@w3.org
> Date: 10/28/2012 06:24 AM
> Subject: Review and Comments for Linked Data Platform FPWD
>
> Hi all,
>
> Many of you know how late I am getting involved in the LDP WG.  Fewer of you
> know how interested I am in this work.  Apologies for the late review of
> this document.
>
> This review relates to Linked Data Platform 1.0 dated 25 Oct 2012 [1]
>
> Caveat 1:  Arnaud asked me last June to provide a summary of the design
> decisions that went into the development of the Callimachus REST API [2],
> but I haven't done it.  I believe that most of the value in such a document
> is implicit in this review.  I have made reference to design decisions and
> practical implementation experience garnered through Callimachus [3].  It is
> our intention to ensure that Callimachus becomes compliant with this
> document (and it appears to be close to it now).
>
> Caveat 2:  I am typing this on an airplane, so apologies for any typos and
> munged URLs.
>
> Caveat 3:  This review has become lengthy.  I am willing to edit the
> document to include my non-controversial changes if the editors would like
> the help and I am willing to summarize what is sure to be a disconnected
> thread in a subsequent message.   Please let me know.
>
> Sections:
> A.  Substantive comments on scope and content
> B.  Document style
> C.  Minor grammarical suggestions
>
>
> A.  Substantive comments on scope and content
>
> - What does the LDP WG Charter say about existing implementations?  Can we
> break them?  Unfortunately, I can't check at the moment. The RDF WG is
> required to at least minimize breakage. We might want to keep the principle
> in mind, even though this WG is more free to invent, to avoid causing
> unnecessary trouble for implementors.
>


Since there isn't an existing standard that we can measure breaking or
not, I'm not sure how we can achieve this.  Though I understand the
motivation to have good reason to diverge from what is known as best
practices from a number of commonly deployed implementations.  How can
we state this other than a basic guiding principle of the WG?


> - The Abstract says, "that describe their state using RDF". I suggest
> changing that to "that describe their state using the RDF data model" in
> order to avoid confusion regarding current or future RDF (or other non-RDF)
> syntaxes.  We have seen many people getting confused on this point, from the
> XML and enterprise communities regarding RDF/XML to the current discussions
> related to JSON-LD's relationship to RDF.

Changed.


> - What is the official status of the namespace for ldp: (first referenced in
> Section 2.1, Conventions Used in This Document)?  I don't know W3C's policy
> on namespace registration, but this should probably be an ISSUE unless the
> Team Contacts already have a handle on it.

It is baked as http://www.w3.org/ns/ldp#


> - The first paragraph of Section 4, Linked Data Platform Resource, mentions
> that a LDPRs may contain data regarding a variety of domains.  I agree,
> however the statement that such data could be "religious" in nature made me
> think about logical consistency (specifically, the Christian conception of
> the Trinity seems to have been formulated in a way that under FOL be
> logically inconsistent - c.f. the solutions to the Sabellianism and Arianism
> Heresies). Does the LDP require LDPRs to be logically consistent?  I suggest
> that this document make no statement about logical consistency within LDPRs,
> but thought I should mention it in case others disagree.

No change made.  I haven't heard this discussed in the WG.


> - I have no objection to requiring HTTP/1.1, as defined in Section 4.1.1,
> but am curious why the WG thinks it is necessary.

No change made.  A style decision seems to be leaning towards stating
things instead of remaining silent.


> - Regarding Section 4.1.4, can Servers use DNS aliasing to differentiate
> LDPRs (as with Apache virtual hosts or Callimachus secondary authorities)?
> I'd prefer that they can and the document should probably say so in this section.

No change made.  Perhaps this is an issue that should be raised and
discussed? I'll leave it to you to raise if you feel it is important
enough.


> - I can see where is would be useful in many use cases to have rdf:types
> served in LDPR representations, but am not sure it is so common that Section
> 4.1.7 should make this a SHOULD.  Perhaps MAY (or language to the effect of,
> "it is often useful to") would be more appropriate in the general case?

No change made.  Perhaps an issue is needed here too.


> - Section 4.1.8 references ISSUE-9 (Should properties used in LDPR
> representations be LDPRs?). I think not, because they may be defined as
> *part* of an LDPR (as In a schema document using the hash URL pattern to
> facilitate self-documentation).  Such uses would not seem to match the (non-
> recursive) definition of an LDPR.

No change made. Will wait for resolution to issue-9.


> - I am quite nervous about Section 4.1.9's requirement that LDPR
> representations MUST "use *only* the following standard datatypes" (emphasis
> mine). I think there are several problems with this: If a representation
> fails to use only those datatypes it becomes a legally served non-LDPR (in
> accordance with Section 4.1.3) instead of a non-compliant LDPR and this
> decision would seriously limit any desired application extensions (via
> legitimate RDF and Linked Data extension mechanisms).  This relates to
> ISSUE-6 (Should LDBP say that any kind of user-defined data type is
> disallowed), to which I would strongly vote "no". Simple is good, but
> systematically eliminating existing extension mechanisms seems ill advised.
> I suggest replacing this with something like, "LDPR representations MAY
> include the following datatypes and MUST limit the use of other datatypes to
> the minimum required".

This has already been removed from the spec and moved to the "Deployment Guide".


> - Section 4.1.11 didn't make sense to me until I read Section 4.2. Until
> then, it sounded like the document was suggesting that LDPR was another RDF
> format.  Rewording the second sentence to avoid that problem would fix it.

No changes made.  Not sure problem with text and what wording would
work better, please propose if you still have problems with this.


> - Section 4.1.1 references ISSUE-22 (Need to normatively reference and
> recommend JSON-LD). Similarly, Sections 4.2.2 and 4.2.3 and ISSUE-23 (Remove
> application/rdf+xml as a SHOULD) relate.  I suggest that although the focus
> on Turtle is fine (even preferred) as a MUST, all other current and future
> RDF syntaxes that are W3C Recommendations should be included as SHOULDs.
> That way, LDPR Servers SHOULD accept as many standard RDF formats as
> possible, presumably by using the small number of commonly used parsers.
> Standard RDF formats include or are anticipated to shortly include Turtle,
> RDF/XML, RDFa, n-triples and JSON-LD.  There may be more (or less) some time
> in the future, so it would be nice to future-proof this document so we don't
> need to revisit it for changes to other RDF syntax specifications.  I would
> also be happy with MAY.

These changes have already been made from previous issue resolution.
See sections 4.2.2 and 4.2.3 as examples.


> - Section 4.1.13 references ISSUE-2 (Do LDPR versions get managed in a
> systematic, discoverable way?). I agree that ETags and Last-Modified headers
> are sufficient, but sometimes wonder whether a Server-defined version number
> in a header wouldn't be useful to inform a Client just how many updates they
> may have missed.  James Leigh disagrees with me on that and I am not firm on
> it.  I leave it to the WG.

No changes made.  This issue was close as out of scope for version 1.


> - Section 4.1.13 references ISSUE-16 (Redirection of non-information
> resources to LDPRs). I note that Section 5.3.5.1 mandates that 303 redirects
> SHOULD be used and I like consistency in Client implementations.  Section 5.
> 1.3 also suggests 303 redirection be used for paging.

No changes made.


> - Sections 4.4.1, 4.5.1, 4.7.1, 5.4.1, 5.6.1 and 5.8.1 all relate to
> allowable write operations.  I suggest adding the statement, "An LDPR server
> MAY require a user to be authenticated and authorized before this action is
> permitted." to each of those sections.

No changes made.


Due to some sensitive/private data, I would expect authentication and
authorization to be needed even on read operations.  Would it not make
more sense to make this a general statement about all operations?


> - Section 4.4.1 says that servers MUST ignore certain RDF statements that
> may be provided by a client.  I understand (and am sympathetic to) the
> rationale presented, but am concerned that implementors will have a
> difficult time with this.  Current implementations make use of a small set
> of commonly used parsers to ingest RDF data, often serializing it it
> directly into a data store during streamed parsing.  Should implementors
> plan to change their code to monitor each incoming triple for
> dcterms:modified and dcterms:creator properties with the intention of
> removing them?  I doubt they will do so (due to the performance hit during
> an already slow process).  Then again, perhaps I worried too much about
> this.  Reading more carefully, I can see that those terms may be provided by
> a client but MUST NOT change the relevant state of the server's
> understanding of the state of the LDPR.  Is that what is intended?

Changes made from similar comments and issue.


> - Section 4.4.1 references ISSUE-11 (Do we need to define server-managed
> properties or do we leave them to applications?) in relation to an LDPR PUT.
> ISSUE-20 (Identifying and naming POSTed resources) would seem relate.
> Callimachus requires such PUT and POST requests to contain a slug to assist
> with naming.  I suggest that LDPR adopt this mechanism (or something very
> similar) because to fail to do limits interoperability.  Section 5.4.10
> mentions the problems with client differentiation in relation to domain-
> specific constraints and I agree.  Adopting a mandatory slug for PUTs, POSTs
> and PATCHes would satisfy ISSUE-20 and allow better guidance in Section 5.4.
> 9 (which currently says "application-specific rules").


No changes made.  Issues mentioned will force the change.


> - Why should clients be restricted (MUST NOT) from presuming a known set of
> predicates for a particular server (Section 4.4.4)?  Since this both
> impossible to enforce (or to even know) and servers can throw away any
> triples they don't like, why not make this a SHOULD NOT?

Changes made from similar comments and issue.


> - What is the intent of Section 4.4.6's allowance for LDPR PUTs without an
> LDPC?  Doesn't an LDPR server without LDPC support mean that the PUT would
> go to the root service for processing anyway?  My earlier suggestion
> regarding the use of slugs to request a name could be used to simplify this, I think.

No changes made.  What resource is identified by the Request-URI in
this case is undefined.  Does it need to be defined here?  One could
assume that it is the client minted URI for the resource.


> - In Section 4.4.7, I suggest changing "It is common for LDPR servers to put
> restrictions on representations" to "LDPR servers MAY put restrictions on
> representations". The sentence as it stands now may reflect the original
> Member Submission, but doesn't reflect other use cases in the wild.  I don't
> think the change loses anything, but it does clarify that an LDPR server's
> available options.

No changes made (directly).  This section has already been changed due
to similar comments.


> - Sections 4.5.1 and 4.5.2 touch on ISSUE-24 (Should DELETED resources
> remain deleted?). My personal experience with such "tombstoning" of URIs
> comes from the two Persistent URL implementations that I have been involved
> with (the community PURL software at purlz.org that purl.org and others use,
> and the PURL implementation in Callimachus).  There are certainly some use
> cases (however uncommon) where tombstoning URIs is a good and even necessary
> idea.  Therefore, I suggest resolving ISSUE-24 by stating that LDPR servers
> MAY choose not to recycle DELETED URIs and update Section 4.5.2 to be
> consistent with that decision.

Handled via ISSUE-24.


> - Regarding ISSUE-12 (Can HTTP PATCH be used for resource creation?), I
> suggest not.  That would be ugly and I think we should not do ugly things.

Handled via ISSUE-12.


> - Regarding ISSUE-17 (changesets as a recommended PATCH format), I suggest
> yes.  However, they should probably become a separate Note or Rec in parallel.

Handled via ISSUE-17.


> - Section 4.8 says that the listed RDF vocabularies MUST be used, but the
> third paragraph of Section 5.1 makes the use of rdfs:member optional.  Those
> two states are currently in conflict.  Although Section 5.1 is non-
> normative, the material in it is repeated in Section 5.2.3 (also marked non-
> normative).  The cleanest way to fix this is probably by removing the
> rdfs:member entry from the table in Section 4.8.

This is no longer valid since required RDF vocabulary terms has moved
to the "Deployment Guide".


> - The non-normative Section 5.1.3 says, "LDPCs may support... Paging", but
> the normative Section 5.3.4 says SHOULD.  These should be brought into alignment.

Fixed.


> - The first paragraph of Section 5.1.4 makes a good point that clients may
> wish to order results themselves.  However, the next paragraph throws away
> that flexibility in order to allow pagination.  I understand that we want to
> keep requirements small, but perhaps it is worth discussing whether clients
> should be able to request ordering based on a particular property's value.
> I would imagine that a server could always respond that it doesn't support
> such behavior (a server MAY implement server-side ordering).

No changes made.  Perhaps a use case or driving it with a spec issue
would help this discussion if you think it is necessary.


> - Section 5.3.7 suggests that a client may request a descending order for
> pages, but doesn't provide guidance on how the DESC keyword should be passed
> to the server.

Made change that ascending is the only option. ISSUE-14 exists for
alternate orderings.


> - Section 5.3.7.1 says, "The Linked Data Platform does not define how
> clients discover LDPCs." Has this be decided by resolution or by default?  I
> would like to suggest that a mechanism similar to that found in Callimachus
> would be a very useful addition to this spec: HTTP OPTIONS requests may be
> made on the root URL of a site and on each container to discover relevant
> URLs for navigation via LINK: headers.  Details of our design may be found
> at [2].  The value is to provide a standard mechanism for resource discovery
> on a host or service basis that is consistent with HTTP.  I didn't want to
> raise an issue on this in case it has already been decided by resolution,
> but suggest that this be a MAY, not a MUST, requirement.

No changes made.  This is being worked under issues like ISSUE-32.


> - Section 5.4.8 says that "LDPC servers MUST interpret the null relative URI
> for the subject of triples... as referring to the entity in the request
> body". I understand why you would want to do that, but this is another case
> where implementors should be expected to scream.  You are asking them to
> introspect each triple during ingest just in case it might contain a null
> relative URI in the. subject position.  Then you are asking them to assign a
> URI for the resource before the parsing is known to be valid...

No changes made.  There are a number of issues on this topic and
unclear what change is suggested here.


> - I suggest adding the input documents listed in the LDP WG Charter to the
> Acknowledgements section.

No changes made.  I have not seen this done in other specifications,
do you have some references that I can use as example?


> B.  Document style
>
> - I found the normative and non-normative guidance presented in Section 3,
> Conformance, to be confusing.  There are at least two problems with it: It
> is unclear which content is (e.g.) a guideline or a note and some non-
> normative sections clearly give MAY/MUST requirements.  Please see below for
> specific details regarding the latter problem.

Have updated the conformance section and each section is labeled that
is informative.


> - Section 5.1.3 contains a couple of "mays" in the second and third
> paragraphs that read like they should be MAYs.  Section 5.2 has a bunch of
> MAYs, MUSTs and a SHOULD NOT.  However, both sections are explicitly marked
> non-normative.  This is at best confusing and at worst going to make trouble
> when the document is in Last Call.  I suggest that anyplace there is a
> defined term from RFC 2119 that paragraph or section should be normative.


Changed from RFC 2119.


> - Similarly, Section 5.3.2 (which is normative) references Section 5.1.2 (a
> non-normative section) for details of implementation.  I suggest expanding
> 5.3.2 to include any normative content and changing that section to refer to
> 5.1.2 only for an example.

Made change to 5.3.2.


> C.  Minor grammarical suggestions
>
> - s/A LDPR/An LDPR/g and s/A LDPC/An LDPC/g ; An English "an" is used in
> front of words starting with vowels as they are  *pronounced*, not
> necessarily as they are spelled.  NB: Subjects of the British Crown who may
> titter with bemusement at an American correcting English usage may proceed
> at will.  I can take it ;)

Changes made.


> - I suggest using "Linked Data" in place of "linked data" throughout (e.g.
> in the Introduction) because it is a defined term (in Section 2,
> Terminology).  It is also used that way commonly on the Web as a proper noun.

Changes made.


> - In the last paragraph of Section 1, Introduction, s/will depend on/will
> depend upon/.

Changes made.


> - I believe a paragraph break belongs in Section 2, Terminology, in the
> definition of "Server" after the first sentence (following "sending back
> responses"). The remaining material seems to refer to both clients and servers.

Already fixed.


> - The part of Section 4.7.2 that reads, "It is common for LDPR servers to
> put restrictions on representations" is duplicated from Section 4.4.7 so I
> suggest that it be removed.

Already fixed.


> - In the first paragraph of Section 4.8, I suggest defining or referring to
> the definition of the term "application semantic" and changing "BP resource"
> to simply "resource".

Already fixed.


> - In Section 4.8.3, rdfs:member seems only to apply to LDPCs. Should it move
> to Section 5 or should the Comment field note that it is optionally used for
> container-member relationships?  This only applies if the rdfs:member entry
> is not removed from the table, as suggested above.

Already fixed, since 4.8 was moved out to "Deployment Guide".


> - In the second paragraph Section 5.1.1, s/there will be/there may be/.


No change made, will introduction RFC 2119.


> - In the fourth paragraph of Section 5.1.3, I suggest removing "JohnZSmith".
> The example should be referred to in a consistent manner.

Already fixed.


> - Examples 6 and 7 in Section 5.1.3 aren't quite aligned.  Example 6 shows
> the container has members a3 and a4 that aren't on page 1.  Therefore,
> Example 7 (which purports to show page 2) should show details for a3 and a4,
> but it shows member a5 instead.  Further, the paragraph under Example 7
> notes that there is only one member show on page 2, so updating just Example
> 7 would cause that point to be invalid.  I suggest removing a4 from Example
> 6 and changing a5 to a3 in Example 7.

No changes made.  Have not heard this issue before, there is also a
comment in the representation of Example 6 to show it has been
shortened for reading: "# server initially supplied no data for a3 and
a4 in this response"


> - The material in Section 5.2.3 that duplicates the third paragraph of
> Section 5.1 should be removed ("The membership triples of a container...").

No changes made.  One is a RFC 2119 variant of the other.


> - Section 5.3.2 references Section 5.1.2, but gets its title wrong (the word
> "Only" is missing).

Fixed.


> - Section 5.3.4 references Section 5.1.3 in an inconsistent style: s/5.1.3
> titled "Paging"/5.1.3 Paging/

Fixed.


> - Section 5.3.6.1 extends a highlight color onto the semicolon following
> "ldp:Page". I suggest that the semicolon should probably be a full stop/
> period in any case.

Fixed


> - ISSUE-7's title should be edited: s/permittered/permitted/

Already fixed.


> Whew!

Whew!


> Regards,
> Dave
>
> [1] http://www.w3.org/TR/2012/WD-ldp-20121025
> [2] http://code.google.com/p/callimachus/wiki/REST_API (If I didn't remember
> this URI correctly, please go to [3] and select "Documentation"; there is a
> link to the REST API document near the bottom of that page)
> [3] http://callimachusproject.org
>

Received on Monday, 4 March 2013 18:55:01 UTC