Re: Test cases and examples for dataset entailment

On 11 Sep 2012, at 14:37, Antoine Zimmermann wrote:
> 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)."

Fixed.

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

Just dereference it.

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

*shrug*. I don't see the difference.

<snip httpRange-14/owl:sameAs argument>
> That's why I prefer IRI-IGEXT.

The resource denoted by dbpedia:Tim_Berners-Lee does not have a representation because it does not return a 200 or 301 or 302. With the notion of web-entailment that I defined in the page, there would be no graph of that name. There would be one at <http://dbpedia.org/data/Tim_Berners-Lee>. If you define web-entailment differently then you may get different results, but a debate about the pros and cons of different ways of defining this web-entailment seems like a distraction at this point. I don't wish to get into an httpRange-14 debate.

> 4.3. Direct graph semantics.
> 
> I don't think this is going to fly.

Not sure what you mean by “fly”. It shows an example and use case for extending the semantics. It's not a proposal for standardization.

> It is way too restrictive.

Not sure how it is restrictive. It says that by typing something as rdf:Graph, you can actually make it denote the graph given in a <name,graph> pair. This doesn't seem restrictive to me.

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

I'm not sure how SPARQL Service Description is more flexible than the single term rdf:Graph, or why such flexibility is desirable, or why you consider a semantic extension presented as an example for a possible extension “clutter”, or what's so strong about the semantic constraints in that extension.

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

I don't know what your point is. A semantic extension is not a requirement for hard coding anything in a reasoner.

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

Yeah, and that's exactly the example I gave, except I called it rdf:Graph instead of sd:Graph, and formalized the implicit assumption that :g actually denotes { :bob :employedBy :ibm } as opposed to some other graph. You can't do that just by defining an ontology.

The benefit of formalizing this is that, for example, if I define a Turtle datatype then it will just work, and I can infer

  { :g owl:sameAs ":bob :employedBy :ibm"^^xxx:Turtle }

from the dataset above, modulo namespace declaration.

Best,
Richard




> 
> 
> AZ.
> 
> 
> 
> 
> 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)
>> 
>> http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/Minimal-dataset-semantics#Possible_Semantic_Extensions
>> 
>> 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
> France
> Tél:+33(0)4 77 42 66 03
> Fax:+33(0)4 77 42 66 66
> http://zimmer.aprilfoolsreview.com/
>

Received on Tuesday, 11 September 2012 17:46:45 UTC