Re: Re 2: [TF-ENT] OWL Direct Semantics added

[snip]
>> O.k., let us see how this goes... Personally, I think that adding some
>> simple vocabulary would be good. Something like
>>
>> sd:possibleEntailmentRegime <URI-FOR-Direct-Semantics>, <URI-FOR-SIMPLE>;
>> sd:possibleEntailmentProfile <URI-FOR-DL>, <URI-FOR-QL>.
>
> I assume these together would replace the current sd:supportedEntailment property? Also, I know there had
> been  some brief discussion of the difference between hanging these properties off of the service and off of
> specific graph descriptions (for cases where different entailment applies to different graphs in the dataset).
> Would these continue to be terms with sd:Service as the domain?

I think it would be good to declare a default entailment regime that
will be applied to all graphs that have no special/different
description for the used entailment regime, e.g.,
sd:supportedEntailment becomes something like sd:DefaultEntailmentRegime

This should still be part of the service description. Optionally, the
system can describe (again part of service) that it only accepts
certain inputs since OWL Direct Semantics is only specified for RDF
documents that satisfy the restrictions for OWL DL. Systems that
implement only the OWL EL or QL profile have even stronger
restrictions, E.g.,
sd:supportedEntailmentProfile <URI-FOR-DL>, <URI-FOR-EL>, <URI-FOR-QL>.
or
sd:supportedEntailmentProfile <URI-FOR-QL>.
The URIs for the possible profile restrictions would then be described
in the Instances section I think, maybe they can be instances of
sd:EntailmentProfile. OWL Profiles that describe/impose restrictions
on what is well-formed RDF for the profile are OWL DL, OWL EL, and OWL
QL. Systems that do not use OWL Direct Semantics should not make any
restriction on the input. If a system supports the OWL DL profile, it
also supports OWL EL and OWL QL. It it supports OWL EL, it also
supports OWL QL. It is probably clearer for users if systems always
state all supported profiles although it can be inferred that OWL DL
systems can handle also EL and QL etc. If a system does not specify
anything for this property, it can be assumed that all valid RDF
documents are accepted as input.

> I feel a bit out of my depths with respect to some of the entailment work, but these seem like reasonable things to
> add to the service description vocabulary. With either these new terms or the existing sd:supportedEntailment term,
> though, I wonder what I'm supposed to do with this information if I get back multiple values for the possible regimes?
> I don't currently do a lot of work with reasoning systems, but without a way to request a specific entailment regime
> for a query, having multiple values for sd:possibleEntailmentRegime seems almost as bad as having zero values
> as far as the end user is concerned. Is this relevant for anybody's use cases? There's obviously a lot of potential
> complexity here, but having a useful solution for simple cases would be nice.

I completely agree. Just stating several possible regimes alone does
not help much since then some form of negotiation would be required
for the client to ask the server to use a certain regime for the query
or for all queries of that user. I would like to keep it simple for
now and suggest that a system declares one default entailment regime.
If the system uses other regimes for some graphs in the dataset, then
this can be described in the dataset description/as part of the graph
description, but again, one entailment regime per graph. This means
that the user cannot ask the endpoint to use a certain entailment
regime. Systems say what they do by default or for certain graphs and
that is it. It would be nice if a system could offer the same graph
once with simple and once with RDFS entailment, for example. I am not
sure whether this is possible if the graphs have the same URI/IRI.
E.g., lets assume my system uses by default simple entailment, but I
have a named graph with IRI http://example.com/myExampleForRDFS.rdf
for which the system will use the RDFS entailment regime when
answering queries. Here is my attempt of describing this:

@prefix : <http://www.example.com/>
@prefix sd: <http://www.w3.org/ns/sparql-service-description#>
:myService a sd:Service .
:myService sd:url :SPARQL .
:myService sd:DefaultEntailmentRegime <URIForSimpleEntailment> .
<URIForSimpleEntailment> a sd:EntailmentRegime .
:myService sd:defaultDataset :myDatatset .
:myDataset a sd:Dataset .
:myDataset sd:defaultGraph :myDefaultGraph.rdf .
:myDataset sd:namedGraph :myNamedGraph1.rdf .
:myDataset sd:namedGraph :myExampleForRDFS.rdf .
:myExampleForRDFS.rdf sd:entailmentRegime <URIForRDFSEntailment> .

Here only the named graph with IRI :myExampleForRDFS.rdf uses the RDFS
entailment regime. Since nothing was specified for :myNamedGraph1.rdf,
this named graph uses the default simple entailment. I make another
attempt to describe my OWL EL SPARQL endpoint:

@prefix : <http://www.example.com/>
@prefix sd: <http://www.w3.org/ns/sparql-service-description#>
:myService a sd:Service .
:myService sd:url :SPARQL-OWL-EL .
:myService sd:DefaultEntailmentRegime <URIForDirectSemantics> .
<URIForDirectSemantics> a sd:EntailmentRegime .
:myService sd:supportedEntailmentProfile <URI-FOR-EL>.
<URI-FOR-EL> a sd:entailmentProfile .
:myService sd:defaultDataset :myDatatset .
:myDataset a sd:Dataset .
:myDataset sd:defaultGraph :myDefaultGraph.rdf .
:myDataset sd:namedGraph :myNamedGraph1.rdf .

I hope that clarifies a bit whatI have in mind. I think this will also
satisfy what Andy had in mind (Andy?).
Birte

>
> .greg
>
>



-- 
Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283529

Received on Thursday, 3 December 2009 12:35:55 UTC