Re: SPARQL contracts?

On 11/07/12 15:45, Arthur Keen wrote:
> 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?

Rather than having the query cause inference, the setup is that the 
against a graph with suitable inference capabilities.  The query asks 
whether (and how) a basic graph pattern (a set of triple patterns) can 
be satisfied by the graph.  The idea of materialising some or all the 
inference works to a certain extent (RDFS) but there are some OWL-DL 
inferences that can't be done via materialised.  Property paths can be 
used for RDFS.

	Andy

> 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 Saturday, 14 July 2012 21:12:40 UTC