W3C home > Mailing lists > Public > public-openannotation@w3.org > August 2012

Mandating SPARQL endpoint. NOT. Was: Re: Serialization spec in the OA core

From: Bob Morris <morris.bob@gmail.com>
Date: Thu, 9 Aug 2012 14:58:11 -0400
Message-ID: <CADUi7O7A5rvWsupkNEEKaLCibrah4io=OHMwaf46gTbZ=GRR6g@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 9 August 2012 18:58:40 GMT