RE: more service description terms to consider



> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-request@w3.org]
> On Behalf Of Gregory Williams
> Sent: 03 September 2009 01:52
> To: public-rdf-dawg@w3.org Group
> Subject: more service description terms to consider
> 
> I received an email recently from Keith Alexander asking about the
> service description vocabulary from the perspective of the VoiD work.
> He listed a number of terms that they would like to see included. The
> SD vocabulary strawman proposal[1] included many of the things he
> listed, but there are several more that I thought I'd bring to the
> group so that we can discuss them. Here are the ones he listed that
> aren't currently in the strawman proposal:
> 
> (1) What sort of description does DESCRIBE return? (CBD, SCBD,
> LCBD, ...)
> (2) Do FROM and FROM NAMED fetch graphs from documents over http?
> (3) Unsupported standard bits (eg, some endpoints only do SELECT, not
> DESCRIBE)
> (4) Pointers to the dataset the endpoint "contains" (if any), e.g. if
> I can't include arbitrary RDF graphs, then which local ones can i
> include in a FROM clause?
> (5) Do I have to provide a default dataset?
> (6) Query time-out period
> (7) Pointers to mirrors might be useful
> (8) Whether authentication is required

General comment:

All these have some merit: I find it difficult to see a balance between what we can do in the time and everything that's a good idea.  This is especially true for me (as application writer) in this area because if a property/class isn't useful in my usage, I can just not use it so it has little cost.

What would help me are use cases for service discovery to give a sense what ability is being enabled.  The F&R examples are quite specific.

> 
> I think the 1 and 2 are important here (and 2 has been mentioned
> briefly in discussing how we might access and query service
> descriptions). Knowing what DESCRIBE returns has clear value, but I
> don't think we should be the ones standardizing the types of DESCRIBE
> algorithms (i.e. having a property for this is good, but let someone
> else coin URIs for things like CBD and SCBD).

Re: 1
I agree with your point - define the framework, not coin the URIs which are "owned" by the format creators to define the exact meaning of the concept for that URI.

Re: 2 - I can see a need to know if the graph is up to date - is that the use case here?.
However, this would seem to overlap with HTTP caching and with the graph provider setting the caching timeout on GET of the graph itself.  In HTTP, the graph owner has some responsibility.  I know some systems are doing local graph management and using FROM to name the graphs from the local store but that can be viewed as a "cache" (unless the remote end does not exist).

It might not be so black & white as to whether a graph from FROM is fetched always when the query is run from the point of view of the query engine either.  It might be fetched, cached for a short time locally (based on load?) so it's fetched sometimes not others.  It might come from a shared intermediate cache.

This seems to overlap with a general HTTP/web issue.  Does SPARQL make it different in some way?

> 3 seems like a strange thing for the standard to promote if a goal of
> the standard is to see conforming implementations. I'm not sure how
> common implementations are that don't support big chunks of the
> existing standard.

Agreed.  We'd have to chop the standard up into parts and get into whether that part made sense on it's own.  That could be quite time consuming to do right.

> 4 may be affected by 2, but may also be convenient as a way of saying
> "I *can* load arbitrary data with FROM, but these datasets are already
> loaded and indexed: ...".

This seems to be a quite small, detailed thing to declare.

----

Re: 7 - the original source may not know what mirrors there are but the idea of a "also try <here>" is a good idea.  A stronger form of rdf:seeAlso?

Re: 8 - seems like it is describing the HTTP requirements, and not a SPARQL-specific issue, but maybe I don't understand it properly.  Any other group doing work on the general HTTP case?  It seems like there could be more things here, (c.f. saddle:resultFormat) that are normally dealt with by negotiation at access time.  Where there are existing mechanisms, even when at runtime, not declaration time, we ought to use them and not overlap.

 Andy

> 
> .greg
> 
> [1]
> http://www.w3.org/2009/sparql/wiki/Feature:ServiceDescriptions#Strawman_Propo

> sal_for_Service_Description_Vocabulary_and_URIs
>

Received on Thursday, 3 September 2009 12:27:05 UTC