- From: Bob Morris <morris.bob@gmail.com>
- Date: Thu, 9 Aug 2012 14:58:11 -0400
- To: Robert Sanderson <azaroth42@gmail.com>
- Cc: public-openannotation <public-openannotation@w3.org>
I found it hard to separate the various concerns in my original post. But your response helps me do so; :-) On Thu, Aug 9, 2012 at 1:20 PM, Robert Sanderson <azaroth42@gmail.com> wrote: > Hi Bob, > > >[...] > I agree that it's always possible to provide URI resolution via a > SPARQL endpoint, but we can't mandate the existence or use of SPARQL. >[...] I think that what I wrote in no way mandates the existence or use of a SPARQL endpoint. It merely shows that there is always a way to construct a resolution and dereference using one. In other words, \if/ an OA implementation always serializes as RDF---which is the recommended practice---then every URI can be made dereferencable and there is no reason to make a distinction between those that are deferenceable and those that are not. By contrast I believe the \spec/ presently says that any implementation of the model, and any compliant OA processor, must assume the existence and use of an HTTP protocol service! I hope that the abstract model does not follow such a mandate and therein become something that only applies to Linked Data or something like it (assuming that when standardized LD is still defined in terms of the HTTP transport protocol). In my opinion, transport protocols should not be part of a data or knowledge model. See for example our separation of concerns architecture at http://filteredpush.org/mw/TDWG2010_Annotations_IG_Sessions . There's no particular reason with this layering of models for there to be any specific interaction--- syntactic, semantic, or operational---required between the annotation models and the transport models. I don't yet know what I think the remedy is. It might be as simple as replacing MUST with SHOULD in Sec 2.4, but I'm not sure. I understand that "traditional" HTTP URL resolution and dereferencing is an important special case and that the spec means to address that case. But I think that an implementation that is agnostic about that case should not be bound by things only applicable to that case, and I fear that this is so at the moment. > > Rob > > > On Thu, Aug 9, 2012 at 9:10 AM, Bob Morris <morris.bob@gmail.com> wrote: >> A claim and and a question about the core spec section 2.4 >> http://www.openannotation.org/spec/core/#Serialization >> >> Executive summary: How is it determined if an implementation of OA >> complies with Sec 2.4? >> >> >> 1. My claim: If an Annotation can be serialized as some form of RDF, >> and the Annotation has an HTTP URI, then it is \always/ possible to >> provide a resolution and dereference (in the sense of IETF STD 66 >> (http://tools.ietf.org/html/rfc3986 ) by use of a SPARQL SELECT query >> submitted to a SPARQL 1.1 endpoint for delivery of a serialization of >> a graph which somehow "is" the Annotation graph. This resolution and >> dereference is in no way different from the typical HTTP URI >> resolution and dereference in which the URI is first used as a key to >> a local cache and then used as a parameter to a DNS service request >> which returns an IP address that is then used as a parameter for an >> HTTP protocol request to that IP address. >> >> 2. The question: In the core oa spec, what is the meaning of the >> sentence Sec 2.4 (Serialization >> http://www.openannotation.org/spec/core/#Serialization) "If the >> Annotation has an HTTP URI, then when that URI is dereferenced, the >> Annotation's serialized graph, and only the graph, MUST be returned in >> an appropriate graph serialization format. " ? >> >> As to 1, by resolution and hence dereference, STD 66 does not mean >> that an HTTP URI must be the value of the argument to an HTTP GET request. >> Indeed, as above, it rarely is. It only means that some provision is >> made to determine and apply an access mechanism: >> 'URI "resolution" is the process of determining an access >> mechanism and the appropriate parameters necessary to dereference a >> URI; this resolution may require several iterations. To use that >> access mechanism to perform an action on the URI's resource is to >> "dereference" the URI.' (From rfc3986, Sec 1.2.2). >> Probably my claim is independent of whether the URI is an HTTP URI or >> not, and probably so is the scheme of using a SPARQL endpoint to >> provide dereferencing. >> >> >> As to 2., The sentence in the spec is silent on the nature of the >> resolution (in the sense of rfc 3986) of the URI before dereferencing. >> Hence to be compliant, the above SPARQL-based resolution, the only >> requirement is that the SPARQL query, when launched return the Annotation's >> serialized graph, and only that. My problem is: by what criteria do I >> measure whether this dereference returns "the Annotation's serialized >> graph and only the graph"? In other words, how do I test compliance? >> Perhaps this is really a question for an implementation more than the >> spec. But doesn't >> it still raise the question of how to decide that the implementation meets the >> spec as to the "MUST"s in Sec 2.4? >> As Stian has remarked elsewhere, and as is true even for vanilla HTTP >> URI resolution, there is no expectation that the same resolution and >> dereferencing will today produce the same graph as it did yesterday. >> >> One possibility is that what's meant by returning "the Annotation's >> serialized graph and only the graph" is that the dereferncing returns >> a rooted labelled digraph whose >> root has an edge labelled rdf:type and taget node labelled >> oa:Annotation and that root label is a URI that is >> the same as the "original" . Alas, just about anything could be such a >> graph. Do we >> instead mean that at the time of creation of the Annotation, the graph >> is in some way immutably persisted somewhere (a triple store? I think >> not...) and this "original" is graph-theoretically compared to the >> dereference? What comparison would be useful if the SPARQL endpoint >> supports adding assertions about resources referenced in the >> Annotation--especially resources in the oa namespace, such as the >> addition of another Target? >> >> The above SPARQL mechanism is important to us because we require to >> support a semantic pub/sub Annotation system. Using a SPARQL query >> (usually behind the scenes), users explicitly express a semantic >> interest in what kind of annotation about whose creation and >> publication they wish to be notified. We use SPARQLPuSH >> (code.google.com/p/sparqlpush) to manage the subscriptions and >> notifications. We use Jena Fuseki to provide the SPARQL endpoints. >> Fuseki even supports invoking SPARQL queries via HTTP GET calls, so >> the actual resolution can be to something which is even an HTTP URI, >> though f rfc 3986 does not require that resolution be a mapping of one >> HTTP URI to another. >> >> -- >> Robert A. Morris >> >> Emeritus Professor of Computer Science >> UMASS-Boston >> 100 Morrissey Blvd >> Boston, MA 02125-3390 >> >> IT Staff >> Filtered Push Project >> Harvard University Herbaria >> Harvard University >> >> email: morris.bob@gmail.com >> web: http://efg.cs.umb.edu/ >> web: http://etaxonomy.org/mw/FilteredPush >> http://www.cs.umb.edu/~ram >> === >> The content of this communication is made entirely on my >> own behalf and in no way should be deemed to express >> official positions of The University of Massachusetts at Boston or >> Harvard University. >> -- Robert A. Morris Emeritus Professor of Computer Science UMASS-Boston 100 Morrissey Blvd Boston, MA 02125-3390 IT Staff Filtered Push Project Harvard University Herbaria Harvard University email: morris.bob@gmail.com web: http://efg.cs.umb.edu/ web: http://etaxonomy.org/mw/FilteredPush http://www.cs.umb.edu/~ram === The content of this communication is made entirely on my own behalf and in no way should be deemed to express official positions of The University of Massachusetts at Boston or Harvard University.
Received on Thursday, 9 August 2012 18:58:39 UTC