Re: Agenda miss from today that affects Paging LC decision

On Tue, Jul 29, 2014 at 6:06 PM, Sandro Hawke <sandro@w3.org> wrote:

>  On 07/29/2014 01:48 PM, John Arwe wrote:
>
> > Sandro did not articulate that the #SortValueAscending resource Must
> > be an LDP-RS, but I assume that's his intent unless he proclaims
> otherwise.
> >
> > I think the restriction can be a little looser than that; the
> > "target" of the Link/rel needs to be a linked data resource.   I
> > don't know if that's defined in any spec, though.   It's something
> > you can dereference to get an RDF description of it.    Like, either
> > it's a hash IRI and the pre-hash part is an RDF-Source or it's non-
> > hash and there's a 303 to an RDF-Source that describes it.
>
> That kind of flexibility makes sense at the level of a link relation.
>
> If we stop there, I don't see how it get us interop at the LDP Paging
> level; that would be saying "throw out the existing normative clauses"
> 7.3.3-7.3.6 and basically turn it into the same "follow describedby link to
> find constraints on instances, hope you recognize what you find b/c there's
> no std" pattern.
>
>
> I'd think a server would be able to make a Turtle file available with sort
> orders without breaking anything.    I don't think that should be viewed as
> violating any spec.     Unfortunately, we don't have any Linked Data spec
> to refer to, so I can live with "MUST be LDP-RS".
>

(trying to catch up and make sure I've got it)

Thinking about this "Turtle file" available would imply it is a web
resource whose state is tied to sequence.  Each in-sequence page resource's
state is tied to a paged resource.

Sounds like a bunch of stuff a server needs to keep together versus just
leaving in the representation.  Though we get around this if we limit the
Link header value to be a URI within the response body representation (i.e.
don't require or encourage another fetch).

With that restriction on the Link header, I believe it could be a fine way
for a client to easily determine that a) results are ordered and b) what
the ordering is.

Regards,
Steve


>
> A version of the updates WITHOUT this flexibility (so truer to what we had
> before my last push op) is live now [1] changeset [2].
>
> > Also, for the example, I might call it something more like
> > <#SortLastnameFirstname> to make it more obvious it's domain specific.
>
> In the example (from LDP, added the paging part here) the "Value" part of
> "SortValueAscending" is a direct mapping to o:value which _is_ in the
> domain vocabulary.  But I think I see a way to nudge it in the right
> direction w/o losing that, so I'll do that (#Sort-o.value-Ascending).
>
>
> Yeah, I know o:value is part of the domain, but "value" doesn't sound like
> it would be.
>
>        -- Sandro
>
>
>
> [1] https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-paging.html
> [2] https://dvcs.w3.org/hg/ldpwg/rev/76e5cbeb6b36  ...to first order:
> remove html5 ref,
> remove transfer-encoding,
> move + rename sort criteria linkage to headers, 7.3
> fix "add at end" 6.2.9
>
> Best Regards, John
>
> Voice US 845-435-9470  BluePages
> <http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Internet+address&location=All+locations&searchFor=johnarwe>
> Cloud and Smarter Infrastructure OSLC Lead
>
>
>