Close ISSUE-57, adding that LDP servers MUST advertise LDP with a link header: Link: <http://www.w3.org/ns/ldp/Resource>; rel=type (and noting that we consider rel=type to be shorthand for the rdf:type property). And we/others can subclass ldp:Resource as needed later. link

ADD: LDP Servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR's URL. LDP Servers MUST include an 'Allow' header with the supported HTTP Methods. LDP Servers MUST include an 'Allow-Patch' header per RFC 5789, if the server supports PATCH. link

Close Issue-19 as is, the spec already covers some error cases, if other specific cases need to be addressed they should be pointed out individually link

Close Issue-63, adding a ldp:containerSortCollation, when set to http://www.w3.org/2005/xpath-functions/collation/codepoint, use compare(A,B), when set to another collation, use compare(A, B, C) link

Close ISSUE-67: Full container membership without pagination, saying no. link

Close ISSUE-69, as is, the syntax is opaque and dependent on the implementation link

Close Issue-75, if membershipSubject, membershipPredicate, and membershipPredicateInverse remain in LDP, they MUST be expressed in every LDPC link

09:27:50 <JohnArwe> @sandro, fine if you then add (in the general case) ... for this user. With your version Sandro, does "when it was serialized" have a well-known definition? vs being "since (the last time)..."

John Arwe: @sandro, fine if you then add (in the general case) ... for this user. With your version Sandro, does "when it was serialized" have a well-known definition? vs being "since (the last time)..."←

09:28:20 <Ashok> Arnaud: Should we investigate how we could provide robust pagination?

Arnaud Le Hors: Should we investigate how we could provide robust pagination?←

09:28:32 <ericP> +1 to understanding how an extension could do it making it safe to punt

09:30:56 <JohnArwe> the trivial way to support it via an extension is to have the server add information (header or predicate) saying the equivalent of "all paging is stable" i.e. the server always implements stable paging

John Arwe: the trivial way to support it via an extension is to have the server add information (header or predicate) saying the equivalent of "all paging is stable" i.e. the server always implements stable paging←

09:40:35 <JohnArwe> We should at least set client expectations, e.g. "Clients should assume that container membership and page contents can change across successive HTTP requests, unless the server advertises/offers other behavior."

John Arwe: We should at least set client expectations, e.g. "Clients should assume that container membership and page contents can change across successive HTTP requests, unless the server advertises/offers other behavior."←

10:16:10 <Ashok> Arnaud: You don't want to use 'profile' beacause it is not a recognized term ... you don't want to use RFC 6906?

Arnaud Le Hors: You don't want to use 'profile' beacause it is not a recognized term ... you don't want to use RFC 6906?←

10:16:51 <JohnArwe> lots of discussion to clarify that, in the sense that these link headers might be thought of as 'types', that the set of rdf:type triples in the content (RDF resource types) might (and in fact needs to, in cases like a CMS) might differ from the 'types' exposed via link headers since the latter describes the server's interaction capabilities for the resouce not its content.

John Arwe: lots of discussion to clarify that, in the sense that these link headers might be thought of as 'types', that the set of rdf:type triples in the content (RDF resource types) might (and in fact needs to, in cases like a CMS) might differ from the 'types' exposed via link headers since the latter describes the server's interaction capabilities for the resouce not its content.←

10:36:37 <JohnArwe> @sandro, are you saying that the link relation type = 'rdf:type' or 'type' ? 'type' is in the IANA registry, has the semantics I related before, so has the problem with any existing CMS that I related before.

John Arwe: @sandro, are you saying that the link relation type = 'rdf:type' or 'type' ? 'type' is in the IANA registry, has the semantics I related before, so has the problem with any existing CMS that I related before.←

10:39:51 <sandro> PROPOSED: close ISSUE-57, adding that LDP servers MUST advertise LDP with a link header: Link: <http://www.w3.org/ns/ldp/Resource>; rel=type (and noting that we consider rel=type to be shorthand for the rdf:type property). And we/others can subclass ldp:Resource as needed later.

PROPOSED: close ISSUE-57, adding that LDP servers MUST advertise LDP with a link header: Link: <http://www.w3.org/ns/ldp/Resource>; rel=type (and noting that we consider rel=type to be shorthand for the rdf:type property). And we/others can subclass ldp:Resource as needed later.←

10:40:14 <Ashok> Roger: We need client to be generic ... that should be in the content

Roger Menday: We need client to be generic ... that should be in the content←

10:40:18 <JohnArwe> ...if you plunk a LDPR representation into that, and it has rdf:type=ldp:Resource in the representation, then the CMS would expose that. The CMS has not violated any spec, but it does not treat the resource as anything more than RDF (it's RDF, not LDP). If we re-use Link: 'type',<ldp:Resource> , that CMS is a liar.

John Arwe: ...if you plunk a LDPR representation into that, and it has rdf:type=ldp:Resource in the representation, then the CMS would expose that. The CMS has not violated any spec, but it does not treat the resource as anything more than RDF (it's RDF, not LDP). If we re-use Link: 'type',<ldp:Resource> , that CMS is a liar.←

10:46:40 <sandro> JohnArwe: I'm concerned that some systems will issue this link header automatically when they don't know anything about LDP, because they learned this information from somewhere (eg the content).

John Arwe: I'm concerned that some systems will issue this link header automatically when they don't know anything about LDP, because they learned this information from somewhere (eg the content). [ Scribe Assist by Sandro Hawke ] ←

10:48:51 <Arnaud> RESOLVED: Close ISSUE-57, adding that LDP servers MUST advertise LDP with a link header: Link: <http://www.w3.org/ns/ldp/Resource>; rel=type (and noting that we consider rel=type to be shorthand for the rdf:type property). And we/others can subclass ldp:Resource as needed later.

RESOLVED: Close ISSUE-57, adding that LDP servers MUST advertise LDP with a link header: Link: <http://www.w3.org/ns/ldp/Resource>; rel=type (and noting that we consider rel=type to be shorthand for the rdf:type property). And we/others can subclass ldp:Resource as needed later.←

13:32:25 <Ashok> Re: OPTIONS, the spec says This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.

Ashok Malhotra: Re: OPTIONS, the spec says This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.←

13:35:17 <mesteban> Roger: we could just say we support OPTIONS without specifying the format of the response's body

Roger Menday: we could just say we support OPTIONS without specifying the format of the response's body←

13:35:46 <nmihindu> "A 200 response SHOULD include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., Allow), possibly including extensions not defined by this specification. The response body, if any, SHOULD also include information about the communication options."

Nandana Mihindukulasooriya: "A 200 response SHOULD include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., Allow), possibly including extensions not defined by this specification. The response body, if any, SHOULD also include information about the communication options."←

13:36:14 <mesteban> JohnArwe: the options may apply to the server of the specific URI.

13:41:14 <SteveS> SteveS: OPTIONS has the feature over HEAD in that you do not need to compute various GET-response headers, like: lastModified, etag, content-size, content-type

Steve Speicher: OPTIONS has the feature over HEAD in that you do not need to compute various GET-response headers, like: lastModified, etag, content-size, content-type [ Scribe Assist by Steve Speicher ] ←

14:07:01 <krp> ... if we were to do it like this example, it seems it does much of what we want

... if we were to do it like this example, it seems it does much of what we want←

14:10:23 <krp> Arnaud: whether to change HEAD in 4.6 to OPTIONS, or add a new OPTIONS section after 4.6

Arnaud Le Hors: whether to change HEAD in 4.6 to OPTIONS, or add a new OPTIONS section after 4.6←

14:10:55 <JohnArwe> Proposal: ADD: LDP Servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR's URL. LDP Servers MUST include an 'Allow' header with the supported HTTP Methods. LDP Servers MUST include an 'Allow-Patch' header per RFC 5789, if the server supports PATCH.

PROPOSED: ADD: LDP Servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR's URL. LDP Servers MUST include an 'Allow' header with the supported HTTP Methods. LDP Servers MUST include an 'Allow-Patch' header per RFC 5789, if the server supports PATCH.←

14:12:47 <Arnaud> RESOLVED: ADD: LDP Servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR's URL. LDP Servers MUST include an 'Allow' header with the supported HTTP Methods. LDP Servers MUST include an 'Allow-Patch' header per RFC 5789, if the server supports PATCH.

RESOLVED: ADD: LDP Servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR's URL. LDP Servers MUST include an 'Allow' header with the supported HTTP Methods. LDP Servers MUST include an 'Allow-Patch' header per RFC 5789, if the server supports PATCH.←

14:42:33 <krp> Ashok: no, that's another issue. you have specified what you're sorting

Ashok Malhotra: no, that's another issue. you have specified what you're sorting←

14:43:06 <JohnArwe> This sorting is for strings and untyped literals (which in RDF 1.1 will be treated as strings, and is how most implementations treat them today according to what I heard Sandro say at SemTech)

John Arwe: This sorting is for strings and untyped literals (which in RDF 1.1 will be treated as strings, and is how most implementations treat them today according to what I heard Sandro say at SemTech)←

14:44:58 <krp> Arnaud: what is important is that if it's not stated you don't know which it is

Arnaud Le Hors: what is important is that if it's not stated you don't know which it is←

14:47:01 <Arnaud> PROPOSAL: Close Issue-63, adding a ldp:containerSortCollation, when set to http://www.w3.org/TR/rdf-sparql-query/#OperatorMapping, use compare(A,B), when set to something else, use compare(A, B, C)

14:51:03 <Arnaud> PROPOSAL: Close Issue-63, adding a ldp:containerSortCollation, when set to http://www.w3.org/2005/xpath-functions/collation/codepoint, use compare(A,B), when set to another collation, use compare(A, B, C)

14:54:56 <Arnaud> Resolved: Close Issue-63, adding a ldp:containerSortCollation, when set to http://www.w3.org/2005/xpath-functions/collation/codepoint, use compare(A,B), when set to another collation, use compare(A, B, C)

15:29:51 <JohnArwe> +1 ericP, if we were to require both in many cases of interest to me (re-using existing collections by overlaying LDP onto them) the representation sizes would effectively double; so not only "not as simple", but obviously less scalable

John Arwe: +1 ericP, if we were to require both in many cases of interest to me (re-using existing collections by overlaying LDP onto them) the representation sizes would effectively double; so not only "not as simple", but obviously less scalable←

16:15:55 <JohnArwe> My expectations are that any given resource would only allow one method of updating membership triples. We allowed PATCH primarily due to the scaling issues for large-membership containers (PUT does not scale past some client and/or server limit)

John Arwe: My expectations are that any given resource would only allow one method of updating membership triples. We allowed PATCH primarily due to the scaling issues for large-membership containers (PUT does not scale past some client and/or server limit)←