Re: Updated Protocol WD

On Mon, Apr 13, 2015 at 4:42 AM, Ivan Herman <ivan@w3.org> wrote:

> first and foremost: thanks:-)
>

No problem :)

I was not sure whether you prefer the comments on github or the mailing
> list; I choose the latter.
>

That seems the right place at this stage, until we get to individual items.


> - is it is o.k., and conformant to our specification, that a server
> implements only the features in this specification, or whether we require
> that the server implements LDP 1.0 entirely,


I believe (but would be happy for someone to verify) that the spec as
written is a minimally conformant LDP system, with some SHOULDs upped to
MUSTs, and some SHOULDs and MAYs omitted.



> ie, clients may rely on features not listed in this document (e.g.,
> non-basic Containers). In other words, do we want to define some sort of a
> profile of a general OA server? Personally, I think it is the former, ie,
> we can have OA servers that work along LDP principles, are compatible with
> LDP, but do not implement the whole of LDP


Yes. If LDP wanted everyone to implement e.g. DirectContainers, then they
should have been MUST in the LDP spec :)


(An example for the minor things we will have to specify: the LDP Paging
> doc[1] has a SHOULD for max-member-count; do we want to use a MUST for an
> OA server or keep with SHOULD?


I missed a MUST in there... IMO it's If you support paging you MUST support
max-member-count (and you silently MAY/SHOULD support the others from LDP,
but we make no requirements)


> The paging spec allows for paging on individual resources, e.g., in terms
> of number of triples or size in KB; do we want OA servers to allow for
> paging on individual annotations, or not? etc…)
>

That's what max-member-count is (where membership and containment happen to
be identical sets in this case, though not necessarily in LDP when you get
beyond basic containers)


One particular issue is the role of turtle vs. JSON-LD. In my
> understanding, the LDP server is based on Turtle as a default, and you have
> to explicitly specify JSON LD as a preferred format in an Accept header if
> you want JSON-LD and not Turtle.


Yes, indeed a drag.  However it's not quite that strict:

* 4.3.2.1 says MUST give Turtle if requested
* 4.3.2.2 says SHOULD give Turtle if no Accept header
* 4.3.2.3 says MUST give JSON-LD if requested

See:  http://www.w3.org/TR/ldp/#ldprs-get-turtle

So we can choose to ignore the SHOULD of 4.3.2.2, and instead state that
you SHOULD give JSON-LD if there's no Accept header.  We could say MUST and
be conformant, but it would make implementation harder if you're starting
from a system that supports LDP as written but easier when you're not.


- We will have to find out what the status is of the LDP Paging[1] and PDP
> Patch documents[2]. It is a bit of a concern that [1] has been in Candidate
> Rec since mid-December; are we sure this will become a Rec? (I will ask
> around.)
>

As you discovered, paging is going to be a Note, and Patch is moving
through the system towards TR.


- I am a bit worried about the complexity of LDP Patch[2]. The
> specification seems to be fairly complex, with its own Turtle-like patch
> language.


Yes, but the alternatives are not much better:

* JSON-PATCH (rfc 6902: https://tools.ietf.org/html/rfc6902)
   -- LD Patch is very similar to JSON patch
* SPARQL Update:
http://www.w3.org/TR/2013/REC-sparql11-update-20130321/#updateLanguage
   -- Very RDF heavy, of course
* Plain old diff
   -- Would mean that there MUST be a single serialization to apply the
diff to, which makes implementation hard with blank nodes that have dynamic
identities



> This may go beyond what we need; maybe it is worth considering a stripped
> down version for the purposes of OA. As far as I could see, LDP allows the
> usage of any other patch language, it is not bound to [2], the patch format
> is specified in the content-type of the patch operation (looking at example
> 2 of [2])
>

Yes, that's all correct.  A subset of LD Patch or JSON Patch seems
reasonable to me.  Or we could leave it up to implementations ... but
there's already 4 options to choose between.

Rob

-- 
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305