Re: Agenda miss from today that affects Paging LC decision

> 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.

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).


[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
Cloud and Smarter Infrastructure OSLC Lead