Re: Review of Service Description Draft

Hi all,
I think I got an action, although I cannot find it, to comment on the
entailment related issues for the SD doc, which I do below.
Happy Easter,
Birte

On 13 April 2011 08:55, Nico Michaelis <nico.michaelis@sohard.de> wrote:
> This is another reply to ACTION-356. This discharges the action.

[snip]

> * The property sd:entailmentRegime (3.2.5) has the domain sd:NamedGraph. I
> expected it to be sd:Graph; that would make it possible for default graphs
> to have an entailment regime that is different from that of the named ones.
> For now, the only way to impose an entailment regime to the default graph is
> by using sd:defaultEntailmentRegime on the Service - but then all named
> graphs are prohibited to have any additional regimes, which I think is an
> unintended consequence.

Greg, could we swap 3.2.4 with 3.2.5? Then we would have
3.2.3 sd:defaultEntailmentRegime
3.2.4 sd:entailmentRegime
3.2.5 sd:supportedEntailmentProfile

We resolved to allow different regimes per graph:
http://www.w3.org/2009/sparql/meeting/2010-08-03#resolution_6

If you have just one entailment regime, say RDFS, you can just set
sd:defaultEntailmentRegime to that regime. If, in your setting, you
mix regimes, you could set a default regime and then specify the
graphs that differ from that with sd:entailmentRegime. In my
understanding also the default graph could differ, e.g., you have a
couple of named graphs for which you use RDFS seantics, but maybe you
want to apply simple entailment to the default graph, e.g., because
you allow for queries that use FROM <someURI>, which then becomes the
default graph and you don't want to do RDFS on graphs just loaded as
default graph. Thus, I would also understand that sd:entailmentRegime
has as domain sd:Graph. The text would also have to change to say just
graph instead of named graph.

> * The property sd:supportedEntailmentProfile (3.2.4) relates to
> sd:defaultEntailmentRegime . I think it is apt to rename that property to
> sd:defaultSupportedEntailmentProfile . Do we need a
> sd:supportedEntailmentProfile for graphs?

We might actually need that although it won't be relevant in praxis
I'd assume. A setting in which this could occur is, for example, when
you use RDFS by default, but have one or more (named) graphs for which
you use OWL RL with RDF-Based Semantics. Since at the moment only OWL
semantics can be combined with profiles, one could infer that the
profile declaration applies to the OWL RL graphs. OWL RL can, however,
also be used with the direct semantics and it could be confusing if
systems support both OWL Direct and RDF-Based Semantics. I consider it
relatively unlikely that systems will provide one endpoint that does
OWL Direct Semantics and OWL RDF-Based Semantics, but assume we have
such a situation and a system does OWL RDF-Based Semantics with the RL
Profile as default and OWL Direct Semantics with the EL Profile on
some graph via sd:entailmentRegime, then giving both profiles with
sd:defaultSupportedEntailmentProfile doesn't say that the RL profile
is just meant for the graphs that have no special ent. regime.
Assigning profiles to graphs seems wrong though :-(
It seems more appropriate to assign a profile to the entailment regime. E.g.,
<myService> sd:defaultEntailmentRegime ent:OWL-RDF-Based .
ent:OWL-RDF-Based sd:supportedEntailmentProfile prof:RL .
with
@prefix ent: <http://www.w3.org/ns/entailment/>
@prefix prof: <http://www.w3.org/ns/owl-profile/>

I attach a Turtle version (can't write RDF/XML by hand) of your
example extended to contain the above described scenario (default
regime OWL-RDF-Based with RL profile and one named graph with
OWL-Direct as regime and EL profile support).

3.2.4 (or 3.2.5) sd:supportedEntailmentProfile

Relates an instance of sd:EntailmentRegime with a resource
representing a supported profile of the entailment regime. Entailment
profiles are discussed more in SPARQL 1.1 Entailment Regimes
[SPARQLENT].
subPropertyOf: sd:feature
domain: sd:EntailmentRegime
range: sd:EntailmentProfile

[snip]

> * The example covers most of the features of the SD. However, it doesn't
> specify any entailment regimes. I think adding another sd:Service with a
> default graph and a one triple regime would clarify things.

I would also like a Turtle example. Maybe you can just use the one I
provided below...

Birte

> Nico
>
>

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix scovo: <http://purl.org/NET/scovo#> .
@prefix sd: <http://www.w3.org/ns/sparql-service-description#> .
@prefix void: <http://rdfs.org/ns/void#> .
@prefix ent: <http://www.w3.org/ns/entailment/>
@prefix prof: <http://www.w3.org/ns/owl-profile/>
_:s a sd:Service ;
 sd:url <http://www.example/sparql/> ;
 sd:supportedLanguage sd:SPARQL11Query ;
 sd:resultFormat <http://www.w3.org/ns/formats/RDF_XML> ,
<http://www.w3.org/ns/formats/Turtle> ;
 sd:feature sd:DereferencesURIs ;
 sd:extensionFunction <http://example.org/Distance> ;
 sd:defaultEntailmentRegime ent:OWL-RDF-Based .
ent:OWL-RDF-Based sd:supportedEntailmentProfile prof:RL .
ent:OWL-Direct sd:supportedEntailmentProfile prof:EL .
<http://example.org/Distance> a sd:Function .
_:s sd:defaultDatasetDescription _:dsd .
_:dsd a sd:Dataset ;
 sd:defaultGraph _:dg .
_:dg a sd:Graph ;
 void:triples "100"^^<http://www.w3.org/2001/XMLSchema#integer> .
_:dsd sd:namedGraph _:ng1 .
_:ng1 sd:name <http://www.example/named-graph1> ;
 sd:graph _:g1 .
_:g1 a sd:Graph ;
 void:triples "2000"^^<http://www.w3.org/2001/XMLSchema#integer> .
_:dsd sd:namedGraph _:ng2 .
_:ng2 sd:name <http://www.example/named-graph2> ;
 sd:graph _:g2 .
_:g2 a sd:Graph ;
 sd:entailmentRegime ent:OWL-Direct ;
 void:triples "1000"^^<http://www.w3.org/2001/XMLSchema#integer> .

Received on Sunday, 24 April 2011 22:55:00 UTC