RE: nonmon mapping and punning

[related to ISSUE-68]

Bijan Parsia wrote:

>On 4 Mar 2008, at 12:54, Michael Schneider wrote:
>
>> Hi Bijan!
>>
>>> (I also want to point out that TopBraid Composer is Jena based and
>>> claims OWL 1.1 support as of the Submission, I believe. Holger, the
>>> TPC author, talks a lot about using triple oriented 
>toolkits with OWL
>>> and didn't mention this part of the mapping as a problem, IIRC
>>> (pointers to places where he did are welcome). I take that 
>as a weak,
>>> defeasible existence proof that the mapping isn't radically at odds
>>> with Jena.)
>
>Note that this is an aside :)

But maybe a significant one. :)

>> First, I don't believe that TBC deals with the conditional  
>> definitions in the FS-2-RDF mapping, i.e. the question on which  
>> condition which RDF syntax is produced from a given Functional  
>> Syntax expression. Being an RDF based tool, TBC does not have to  
>> care about the Functional Syntax at all, but simply needs to wait  
>> for the resulting RDF documents as its input.
>[snip]
>
>The nonmonotonicity of the mapping is independent of whether you are  
>mapping from FS to RDF. I.e., if I have an ontology representing a  
>pun free ontology as a set of triples, then add a statement which  
>puns and object and data property, then I have to do some  
>modification of the set of triples (i.e., delete someand add more).  
>So, I thought that this was the problem. I don't see that it *is* a  
>problem, since the event monitoring feature can handle it easily,  
>afaict.

I don't think that Jeremy really meant that it is technically impossible,
but more that it doesn't match the general concepts behind Jena, which is an
RDF framework after all.

First, I would like to keep with my own "static" example (with imports),
because I believe this is more what Jeremy had in mind (although he
formulated his example in a procedural form, where one adds triple after
triple into some graph).

Assume you have the following two OWL ontologies in RDF:

  O1 = {
    p rdf:type owl:DatatypeProperty .
    p rdf:type owl:FunctionalProperty
  }

  O2 = {
    _:x owl:import O1 .
    p rdf:type owl:ObjectProperty .
  }

Now, you build an OntModel in Jena, and load O2. You might expect that Jena
does an "automatic repair" by replacing the triple

  p rdf:type owl:FunctionalProperty

with the new triple

  p rdf:type owl11:FunctionalObjectProperty

But, IIRC (Jeremy, please jump in, if I am wrong here!), Jena loads both
ontologies, and treats them as a union, i.e. an RDF merge (a special kind of
triple set union, where bNode name conflicts are resolved first). Jena's
OntModel interface, which is a sub interface of the Model interface (Jena's
object representation of an RDF graph), is only intended to provide a
certain *view* on RDF data. It provides a set of convenience methods for
those combinations of RDF triples, which represent an OWL feature. AFAIU, it
is *not* intended that an OntModel *behaves* significantly different from a
plain RDF Model, in particular not in an OWL specific way. In particular,
loading O2 into an OntModel shouldn't lead to a different result than
manually loading O1 and O2 into two plain Models, then building a union from
these two models, and then building an OntModel from the resulting union
Model. 

Or, if we still regard the procedural example: If I first build an OntModel
from O1, and then add the axioms from O2, then Jena will map these adding
operations just to the respective "addTriple" methods of the more basic
Model interface. I believe that it is not intended to do clever OWL specific
preprocessing first, i.e walking through the graph and looking for possible
conflicts, which are then solved by dropping any triples.

Again, it *would* certainly be technically possible to do so. But when I
correctly understand the situation, the Jena team does not seem to like this
idea, because Jena is essentially an RDF framework, not an OWL framework. Of
course, software which works on top of Jena (such as TBC) *may* do the
necessary OWL specific jobs itself. So, again, there is not a show stopping
*technical* problem here. 

The problem seems rather to be that the following simple transformation
scheme will not valid anymore:

  FS(O1) + FS(O2)  -- FS-to-RDF --> RDF(O1) + RDF(O2)

        |                                |
        |                                |
  build FS union                   build RDF union
        |                                |
        V                                V

   FS(O1 + O2)   <-- RDF-to-FS --    RDF(O1 + O2)


Cheers,
Michael

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