Re: Review of Service Description Draft

On Apr 24, 2011, at 6:54 PM, Birte Glimm wrote:

> 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

Yes, I'll make this change.

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

My recollection is that sd:entailmentRegime had a domain of sd:NamedGraph, because the entailment is a feature of the sparql service, not the graph. For example, you could have have something like a single graph available as the default graph with simple entailment, and via a named graph with RDFS entailment:

[] a sd:Service ;
	sd:defaultDatasetDescription [
		a sd:Dataset ;
		sd:defaultGraph _:graph ;
		sd:namedGraph [
			sd:name <http://www.example/named-graph> ;
			sd:graph _:graph ;
			sd:EntailmentRegime entailment:RDFS ;
		] ;
	] .

_:graph a sd:Graph ;
	void:triples 100 .


Does that make sense? I don't generally work with entailment regimes at this level, so will change it if others think this isn't important, but I think that's why it was done originally. It does make describing entailment that applies just to the default graph difficult, though.


>> * 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 agree that assigning profiles to graphs seems odd, but assigning a profile to, e.g., ent:OWL-RDF-Based would only be useful if you could guarantee that multiple SD documents aren't loaded into the same store and merging the profiles that are claimed on any particular entailment regime (you'd also obviously need to assume closed world semantics). I have no idea what to do with this. Do you or anyone else with entailment experience have concrete suggestions for how to proceed?

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

Aesthetically, I'd also prefer turtle but I was hesitant to use Turtle over RDF/XML as it's not (yet) an actual standard.

.greg

Received on Tuesday, 26 April 2011 01:52:12 UTC