W3C home > Mailing lists > Public > public-owl-wg@w3.org > January 2008

FW: Proposal and Test cases (Re: skolems: visible differences?)

From: Michael Schneider <schneid@fzi.de>
Date: Thu, 17 Jan 2008 10:15:15 +0100
Message-ID: <0EF30CAA69519C4CB91D01481AEA06A06C2445@judith.fzi.de>
To: "Jeremy Carroll" <jjc@hpl.hp.com>
Cc: "Web Ontology Language ((OWL)) Working Group WG" <public-owl-wg@w3.org>
Jeremy Carroll wrote:

>TEST 5:
>     ObjectPropertyAssertion(:p :x _:y)
>does not entail
>     ObjectPropertyAssertion(:p :x _:y)

For my understanding: Is the purpose of this testcase to show that each
occurrence of the same bNode under skolem semantics actually stands for a
fresh variable? So even an additional axiom

  SameIndividuals(_:y _:y)

wouldn't help, since this is not better than stating

  SameIndividuals(<u> <w>)

for otherwise unused URIs '<u>' and '<w>'. Is this right?

Ok, this is actually how I understand skolems. And this is also the way how
I would best understand the term "anonymous variable". So for me, this means
(at the moment) that anonymous variables are properly represented by

However: Using bNodes for this purpose is *very* confusing for me, and I
don't believe that it really matches user expectations (from the user
expectation's point of view, this is no big progress compared to seeing
bNodes as existentials, IMHO).

A particular problem would arise with RDF syntax, when people use bNodes in
their assertions, like in

  _:x foaf:name "John Doe" .
  _:x foaf:homepage <http://www.ex.org/johndoe> .

That's common use in FOAF (although often the bNode is hidden behind a "[]"
in Turtle syntax, and there is also normally no explicit mentioning of the
bNode in RDF/XML). The 1.1-DL semantics of this RDF graph would then be
given by inverse-mapping it to Abstract Syntax. It would result in
  DataPropertyAssertion(foaf:name _:x "John Doe") .
  ObjectPropertyAssertion(foaf:homepage _:x <http://www.ex.org/johndoe>) .

But with skolem semantics for the bNode(s) '_:x' this would be totally
different from what was intended by the RDF version's author.
An alternative suggestion would be to use a special "dummy" variable like
"_", as in Haskell. Then, the above test would become

  TEST 5':
     ObjectPropertyAssertion(:p :x _)

  does not entail

     ObjectPropertyAssertion(:p :x _)  

And my sameness axiom would be

  SameIndividuals( _ _ )

I would not be confused by this, since I would know about the special
meaning of "_" (easy to remember, since there is no precedence for the use
of "_" somewhere else in the SemWeb).

The RDF mapping would then have to build fresh names (bNodes, probably) for
each occurrence of a "_". This is not very nice, but I think it would be
simple to implement. But roundtripping would perhaps become a problem: One
would need to know somehow, which bNode may be mapped to a "_" and which
not. Perhaps this is a point, where roundtripping shouldn't be enforced by
the spec. The alternative, to simply map each bNode in RDF to the same bNode
in the Abstract Syntax would at least bring no problems, AFAICT.

More discussion needed, esp. whether anonymous variables in Abstract Syntax
are important enough to force the WG coping with this topic at all.

... who has finally recovered from scrolling blindness of yesterday's
telecon, still heaving a headache.

Dipl.-Inform. Michael Schneider
FZI Forschungszentrum Informatik Karlsruhe
Abtl. Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: Michael.Schneider@fzi.de
Web  : http://www.fzi.de/ipe/eng/mitarbeiter.php?id=555

FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts
Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Rüdiger Dillmann, Michael Flor, Jivka Ovtcharova, Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus

Received on Thursday, 17 January 2008 09:15:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:02 UTC