Re: the state of ldp-patch, and a procedural proposal

> Just out of curiosity, what exactly do you mean by hash URI?
A URI with a non-empty fragment component.
(I have this nagging feeling that I'm answering the question I think you 
asked, but not the one you're interested in, so if that's the case please 
re-phrase - for a reasonably complete example, see [1]).

> So you'd be happy with a PATCH that had support for list operations 
> but not blank nodes?

Lists => blank nodes => indexing issues, so we eschew lists generally.
I.e. "my" implementations likely don't need list operations either.
Aside from cases where we want to convey sorting (which is more a property 
of the representation than the resource's state), we find straight 
(LDP-like) containers do what we need.
Where we do need to convey sort info, I think we fall back to non-standard 
means that map reasonably well to LDP's sort criteria.
We also very rarely use rdf:Seq (and never Bag or Alt) ... [1] is the only 
use of it I am aware of in my area, where information like "top 5 CPU 
hogs" is being conveyed.

> Do you ever have a subject s, a predicate p, and TWO values, v1 and 
> v2, BOTH of which are lists?

At this point, I am aware of exactly zero uses of rdf:List in my area.

> If you were ever to have that, can you think of any way you could 
> indicate in a patch which list was to be modified?

No (off the cuff).  At least none that work given 2 seconds of thought.


[1] 
http://open-services.net/wiki/performance-monitoring/OSLC-Performance-Monitoring-2.0-Appendix-A:-Samples/


Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario