- From: Arthur Keen <AKeen@algebraixdata.com>
- Date: Wed, 11 Jul 2012 14:45:08 +0000
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- CC: "<public-rdf-dawg@w3.org>" <public-rdf-dawg@w3.org>
Thanks very much for clarifying this. To paraphrase: Encoding the the contracts directly as triple patterns keeps it in specification and we can implement it by either 1) matching directly against metadata (encoded in the graph or in a catalog as a VoiD or OML, etc) about the graph being queried or 2) wrap in a service call to the SPARQL service description. Would it make sense to implement SPARQL functions (e.g., magic property) that cause the entailments to be computed dynamically? On Jul 10, 2012, at 3:04 AM, Andy Seaborne wrote: > The "SPARQL 1.1 Service Description" > > http://www.w3.org/TR/sparql11-service-description/ > > vocabulary would meet part of this by describing the endpoint requirements. There are ways to describe the data, such as VoiD. > > Andy > > On 10/07/12 04:54, Arthur Keen wrote: >> Disclaimer: I am not asking this question for SPARQL 1.1 >> specification >> >> When one encounters a query in the wild, it is often difficult to >> reverse engineer the situation or conditions it was intended for. For >> example, what entailment regime it needed. I have been wondering >> whether the idea of a SPARQL query "contract" has ever come up during >> the W3C SPARQL 1.0 or 1.1 specification process. By "contract" I >> mean conditions that specify requirements that need to be met by the >> environment in which the query is to be executed. For example, the >> entailment regime required by the query or the set of one or more >> graphs that are required by the query (e.g., FOAF or DC) to be >> present when it is executed, etc. Does this make sense? Was it >> ever discussed? >> >> Best regards Arthur >> > >
Received on Wednesday, 11 July 2012 14:49:57 UTC