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

I agree that it is best to put Serialization and Publishing in their
own section.  All the easier to try to argue that normative models of
neither belong in OA.  Hah, hah, just serious.  :-)

Bob



On Thu, Aug 9, 2012 at 3:48 PM, Robert Sanderson <azaroth42@gmail.com> wrote:
> On Thu, Aug 9, 2012 at 12:58 PM, Bob Morris <morris.bob@gmail.com> wrote:
>> 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.
>
> Very true.  I meant to say that although it's possible to use a SPARQL
> endpoint to resolve and thereby dereference an Annotation with an HTTP
> URI that does not provide a serialization *directly* via its own HTTP
> URI, we cannot require this approach.  We should, of course, make sure
> that we're not doing anything to prevent it!
>
>> 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!
>
> Yes ... when the Annotation is identified by an HTTP URI.
>
> And to short circuit slightly ... We could move section 2.4 and
> section 6.4 into their own section 7 regarding protocols and
> transports, separating the concerns more cleanly between data model
> and implementation.
>
> Rob



-- 
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 20:12:42 UTC