- From: Bob Morris <morris.bob@gmail.com>
- Date: Thu, 9 Aug 2012 11:10:17 -0400
- To: public-openannotation <public-openannotation@w3.org>
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.
Received on Thursday, 9 August 2012 15:10:51 UTC