W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2011

Re: Review of Service Description Draft

From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
Date: Wed, 27 Apr 2011 11:37:55 +0100
Message-ID: <BANLkTinkmJa44BgULxRS9bhgM7v1+KtG2g@mail.gmail.com>
To: Gregory Williams <greg@evilfunhouse.com>
Cc: Nico Michaelis <nico.michaelis@sohard.de>, public-rdf-dawg@w3.org
On 26 April 2011 02:51, Gregory Williams <greg@evilfunhouse.com> wrote:
> On Apr 24, 2011, at 6:54 PM, Birte Glimm wrote:
>
[snip]

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

Ok, seeing it in context of a concrete example, it makes more sense. I
think you are right in saying that we decided to have the default ent.
regime as declared and then you can have named graphs with different
regimes as in the above example, so sd:NamedGraph as domain then makes
sense.

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

I hope that would anyway be an unusual case. In my case, I would
always have one default entailment regime and that's it.

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

This seems to be the problematic bit. As I would always have OWL
Direct Semantics for everthing (supporting the EL, QL, and RL
profile), I am in an easier situation. The problem kicks in, when you
sart to mix regimes.

Maybe the best solution is then to stick with stating also for each
graph that has a non-standard entailment regime, which profiles are
supported, e.g., by having (as suggested)
sd:defaultSupportedEntailmentProfile and sd:supportedEntailmentProfile
for (named) graphs.

[snip]

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

Maybe in an informative section?

Birte

> .greg
>
>



-- 
Dr. Birte Glimm, Room 309
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283520
Received on Wednesday, 27 April 2011 10:38:25 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:46 GMT