Re: {a draft proposal} How to publish SPARQL endpoint limits/metadata?

Hello Ghislain,

Thank you very much for your efforts! To my amateur eyes it looks like 
just the sort of thing that is needed, should it be widely adopted.

As for the details, I tried to form a better understanding of the SPARQL 
1.1 Service Description 
(http://www.w3.org/TR/sparql11-service-description/), since that is 
vocabulary that is extended. But some things I did not get:

  * I was wondering whether it would be good to know the version(s) of
    the SPARQL Protocol that is supported by an endpoint. I have just
    noticed that the Service Description vocabulary is for SPARQL 1.1
    only, not for SPARQL in general (including past and future
    versions). Does this mean that a user agent can infer that the
    service supports version 1.1 of SPARQL if it is described by the
    SPARQL 1.1 Service Description? And will it be probable that new
    vocabularies will be published to describe future versions of SPARQL?
  * In the abstract it says /"//These descriptions provide a mechanism
    by which a client or end user can discover information about the
    SPARQL service such as supported extension functions and details
    about the available dataset//"/. Note the singular in the last word:
    dataset. Does this mean that a 1:1 relationship between services and
    datasets is assumed?
  * I think I have always seen a SPARQL Service and a SPARQL endpoint as
    being the same thing. But looking closely at the SD vocabulary, I
    see they are modelled as different things. I think it is important
    to understand the difference, but I could not find a description of
    the difference between a SPARQL endpoint and a SPARQL service.
    However, I do find web resources that seem to equate the two, like
    this text from the SPARQL overview
    (http://www.w3.org/TR/sparql11-overview/) : /"//Assuming the graph
    data from above is loaded into a SPARQL service (i.e., an HTTP
    service endpoint that can process SPARQL queries) ..//. "//. /I am
    afraid I am confused...

As for the proposal, here are some remarks:

  * I was taught at school that it is good practice to always use whole
    SI units. I notice you use milliseconds to denote the query timeout
    value. Wouldn't it be better to use seconds (regardless of present
    day common practice)?
  * Why is sdm:maxResultsPerRequest a property of sdm:SPARQLRequest?
    Isn't the limit always the same across for all requests that can be
    sent to the endpoint?
  * Shouldn't  sdm:maxResultsPerRequest and sdm:remainingPerRequest be
    of type xsd:integer?

Greetings,
Frans

On 2013-10-14 15:16, Ghislain Atemezing wrote:
> Hi Frans, all
> I've started a draft vocabulary for discussion re this thread.
> I've re-used the following classes in other vocabulary namespaces 
> sd:Feature; http:Message, interval:CalendarInterval, dctype:Software 
> and org:Organization.
>> Below are some things that I think would benefit communication between
>> SPARQL endpoints and user agents. Please know that I am a novice in
>> Linked Data, so perhaps some of these are already covered by existing
>> standards or best practices, or do not make sense.
>>
>>  1. The maximum number of results per request (hard limit)
>>  2. The amount of remaining requests (This could be used for a
>>     throttling mechanism that allows only a certain amount of request
>>     per unit of time and IP address. I remember having talked to a data
>>     service on the web where this information was put in the HTTP
>>     response headers)
>>  3. The time period of the next scheduled downtime
>>  4. The version(s) of the protocol that are supported
>>  5. (the URI of) a document that contains a human readable SLA or fair
>>     use policy for the service
>>  6. URIs of mirrors
> Please find attached the .ttl file and a graph representation.
>
> So, let's start from here ?!
> @TODO: Any idea for a place to collaboratively update this draft? 
> github? W3C community group ? a volunteer to host in his/her server?
>
> HTH
>
> Ghislain
>


-- 
--------------------------------------
*Geodan*
President Kennedylaan 1
1079 MB Amsterdam (NL)

T +31 (0)20 - 5711 347
E frans.knibbe@geodan.nl
www.geodan.nl <http://www.geodan.nl> | disclaimer 
<http://www.geodan.nl/disclaimer>
--------------------------------------