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

Birte Glimm wrote:
> [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.

Just on a very technical and minor note: after discussions with the SW
CG, there are common URI-s now for the entailment regimes, see

http://www.w3.org/ns/entailment/


I would be happy to set up a similar set of generic URI-s for the
profiles (including DL).

Ivan

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

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf