Re: Test cases and examples for dataset entailment

Follow-up of my two previous emails:

4.1. owl:imports entailment.

Good. Minor suggested change:

"If <r1,r2> in IEXT(I(owl:imports)) and IGEXT(r2) is defined then 
IGEXT(r1) entails IGEXT(r2)."


"If <r1,r2> in IEXT(Id(owl:imports)), IGEXT(r1) and IGEXT(r2) are 
defined then IGEXT(r1) E-entails IGEXT(r2)."

Remark: if we opt for IRI-IGEXT, then the definition becomes:

"If <Id(n1),Id(n2)> in IEXT(Id(owl:imports)), IGEXT(n1) and IGEXT(n2) 
are defined then IGEXT(n1) E-entails IGEXT(n2)."

4.2. Web entailment.

"If r is a web resource with at least one representation in an RDF format"

this condition cannot be checked by a reasoner. You need an oracle that 
tells you when an IRI denotes a web resource. This oracle may be 
something like httpRange14 or simply a dereferencing function + 
reasoning to detect identity.

This means that there must be one more step of indirection, which you do 
not have if you use IRI-IGEXT. With IRI-IGEXT, Web entailment associates 
with an IRI whatever RDF graph you get by dereferencing the IRI.

I'm pretty sure that most people would rather like to say that the graph 
associated with an IRI is what can be looked up using HTTP or an 
appropriate proptocol. For instance, the graph at

  freebase:Tim Berners-Lee

would have the triples that are found in the freebase database, not the 
triples found at:









  ...154 other web addresses that are owl:sameAs TimBL

That's why I prefer IRI-IGEXT.

4.3. Direct graph semantics.

I don't think this is going to fly. It is way too restrictive. I believe 
that what we need is a flexible vocabulary à la Service description. 
Such a vocabulary should not clutter RDF reasoners with strong semantics 
constraints. However, people who are interested in implementing support 
for the vocabulary can interpret the terms in a special way. People 
already do that. There are tools that display instances of foaf:Person 
in a special way. There are Web crawlers that interpret the voiD 
vocabulary in a special way. They do not need that the special 
interpretation be hard coded in reasoners.

If I had to directly talk about a graph in a named graph, I would do it 
like this:

:g  a  sd:Graph;
     :validityTime  "1998-09-11"^^xsd:date;
:g  {  :bob  :employedBy  :ibm }

It works, as long as I am using an agreed upon, explicit specification 
of a shared conceptualisation, a.k.a. an ontology.


Le 11/09/2012 11:46, Richard Cyganiak a écrit :
> On 10 Sep 2012, at 17:30, Richard Cyganiak wrote:
>> Two other things that I'd quite like to see before we can call the proposal complete:
>> 1. Some thinking on how it addresses our graph use cases. (Do we have an “official” list of those? I've lost track with all the various documents.)
>> 2. Some examples for semantic extensions, in order to show that various other proposed semantics can actually be done as proper semantic extensions of this minimal dataset semantics.
> I've worked a bit on this item and made attempts to formalize three semantic extensions:
> * owl:imports (formally explains how owl:imports works in RDF datasets)
> * web datasets (formally defines that stuff published on the web is asserted)
> * direct graph semantics (permits "literal" immutable graphs)
> I'm not proposing that we should standardize any of this; the intention is merely to explore how flexible/extensible the semantics proposed on that page is.
> Again, I'm not really good at this formal semantics stuff, so this might all be spectacularly wrong.
> Best,
> Richard

Antoine Zimmermann
ISCOD / LSTI - Institut Henri Fayol
École Nationale Supérieure des Mines de Saint-Étienne
158 cours Fauriel
42023 Saint-Étienne Cedex 2
Tél:+33(0)4 77 42 66 03
Fax:+33(0)4 77 42 66 66

Received on Tuesday, 11 September 2012 13:37:33 UTC