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

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).

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.

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: ...".

.greg

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

Received on Thursday, 3 September 2009 00:52:45 UTC