- From: James Smith <jgsmith@gmail.com>
- Date: Tue, 29 Jan 2013 09:19:07 -0500
- To: public-openannotation <public-openannotation@w3.org>
- Cc: Antoine Isaac <aisaac@few.vu.nl>, Robert Sanderson <azaroth42@gmail.com>
On Jan 28, 2013, at 5:39 PM, Robert Sanderson <azaroth42@gmail.com> wrote: > On Mon, Jan 28, 2013 at 2:33 PM, Antoine Isaac <aisaac@few.vu.nl> wrote: >> Hi Rob, > >>> I've added: >>> The URI SHOULD NOT be resolvable, but if it is, then an RDF >>> description of the construct MUST be returned. >> >> I think the SHOULD is a bit strong, but as I can't really calculate the >> consequences right now, I'll abstain from objecting. >> And yes, if I de-referenced a Choice I'd expect to get the RDF description >> of the Choice. > > I could reduce SHOULD NOT to MAY? eg The URI MAY be resolvable, ... > > The concern is the same as other identity management issues -- we want > to allow these nodes to be referred to from other Annotations and > Linked Data descriptions, but don't want to imply that they should be > dereferencable. Especially Choice/Composite/List seem pointless to > have as resolvable URIs when all you would get is already in the > Annotation's serialization. > +1 on changing SHOULD NOT to MAY with the caveat that the RDF returned by dereferencing the URI should reinforce (or not contradict) the RDF in the graph associated with the URI. My tendency when designing systems that provide graphs (thinking specifically of our Shared Canvas effort in the Shelley-Godwin Archive here), is to provide the piece of the graph named by a URI when that URI is dereferenced, even if that URI and its information is contained in another graph. Part of this is because that URI is useful for managing the graph via a REST-style API, but we don't want an application having to make a hundred HTTP requests to build out the manifest before we can show content to the reader. -- Jim
Received on Tuesday, 29 January 2013 14:19:36 UTC