# Custom import ontology button problem

12 messages
Open this post in threaded view
|

## Custom import ontology button problem

 Hello all,Ive been really struggling with an import ontology button im working on...For the plug in im building it is basically a custom interface allowing users to describe a specific ontology. Since every ontology is built on the same one i import that by default, however  the default ontology can change (The url of it)So i am adding a quick fix button that allows the user to import what ever ontology they want. to by plug in. And everything works fine unlessThe users imports an ontologydeletes itand then re imports itI get an error that says naming conflict etc. However protege seems to handle what ever conflict when you use their built in features. My question is what do i need to do  to handle the conflict, or where are the protege files that handle it. ive been loking but cant find anything...Anyway great to be working on protege again! hopefully someone can help me out!W

_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback
Open this post in threaded view
|

## Re: Custom import ontology button problem

Rookie mistake... here is the error that my app gives

Error logged
java.lang.RuntimeException: java.lang.RuntimeException: org.semanticweb.owlapi.model.OWLOntologyRenameException: Could not rename ontology. An ontology with this ID already exists: <http://ecoinformatics.org/oboe/oboe.1.0/oboe.owl>
at org.protege.owlapi.model.ProtegeOWLOntologyManager.callWithWriteLockUnchecked(ProtegeOWLOntologyManager.java:193)
at org.protege.owlapi.model.ProtegeOWLOntologyManager.applyChange(ProtegeOWLOntologyManager.java:137)
at org.coode.owlapi.rdfxml.parser.OWLRDFConsumer.applyChange(OWLRDFConsumer.java:826)
at org.coode.owlapi.rdfxml.parser.TypeOntologyHandler.handleTriple(TypeOntologyHandler.java:29)
at org.coode.owlapi.rdfxml.parser.OWLRDFConsumer.handleStreaming(OWLRDFConsumer.java:1563)
at org.coode.owlapi.rdfxml.parser.OWLRDFConsumer.statementWithResourceValue(OWLRDFConsumer.java:1538)
at org.semanticweb.owlapi.rdf.syntax.RDFParser.statementWithResourceValue(RDFParser.java:556)
at org.semanticweb.owlapi.rdf.syntax.RDFParser$NodeElement.startElement(RDFParser.java:848) at org.semanticweb.owlapi.rdf.syntax.RDFParser$NodeElementList.startElement(RDFParser.java:777)
at org.semanticweb.owlapi.rdf.syntax.RDFParser.startElement(RDFParser.java:261)
at org.coode.owlapi.rdfxml.parser.RDFXMLParser$1.startElement(RDFXMLParser.java:52) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:501) at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java:767) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:400) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2755)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) at javax.xml.parsers.SAXParser.parse(SAXParser.java:395) at org.semanticweb.owlapi.rdf.syntax.RDFParser.parse(RDFParser.java:153) at org.coode.owlapi.rdfxml.parser.RDFXMLParser.parse(RDFXMLParser.java:80) at uk.ac.manchester.cs.owl.owlapi.ParsableOWLOntologyFactory.loadOWLOntology(ParsableOWLOntologyFactory.java:165) at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:687) at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntologyFromOntologyDocument(OWLOntologyManagerImpl.java:644) at edu.gonzaga.oboe.OBOETreeHierarchy.importDifferentOboe(OBOETreeHierarchy.java:217) at edu.gonzaga.oboe.OBOETreeHierarchy.access$3(OBOETreeHierarchy.java:211)
at edu.gonzaga.oboe.OBOETreeHierarchy$2.actionPerformed(OBOETreeHierarchy.java:169) at org.protege.editor.core.ui.view.ViewActionAdapter.actionPerformed(ViewActionAdapter.java:52) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236)
at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:272)
at java.awt.Component.processMouseEvent(Component.java:6267)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
at java.awt.Component.processEvent(Component.java:6032)
at java.awt.Container.processEvent(Container.java:2041)
at java.awt.Component.dispatchEventImpl(Component.java:4630)
at java.awt.Container.dispatchEventImpl(Container.java:2099)
at java.awt.Component.dispatchEvent(Component.java:4460)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4577)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4238)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168)
at java.awt.Container.dispatchEventImpl(Container.java:2085)
at java.awt.Window.dispatchEventImpl(Window.java:2478)
at java.awt.Component.dispatchEvent(Component.java:4460)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
Caused by: java.lang.RuntimeException: org.semanticweb.owlapi.model.OWLOntologyRenameException: Could not rename ontology. An ontology with this ID already exists: <http://ecoinformatics.org/oboe/oboe.1.0/oboe.owl>
at org.protege.owlapi.model.ProtegeOWLOntologyManager.callWithWriteLockUnchecked(ProtegeOWLOntologyManager.java:193)
at org.protege.owlapi.model.ProtegeOWLOntologyManager.applyChanges(ProtegeOWLOntologyManager.java:150)
at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.applyChange(OWLOntologyManagerImpl.java:427)
at org.protege.owlapi.model.ProtegeOWLOntologyManager.applyChangeSuper(ProtegeOWLOntologyManager.java:132)
at org.protege.owlapi.model.ProtegeOWLOntologyManager.access$200(ProtegeOWLOntologyManager.java:26) at org.protege.owlapi.model.ProtegeOWLOntologyManager$3.call(ProtegeOWLOntologyManager.java:140)
at org.protege.owlapi.model.ProtegeOWLOntologyManager$3.call(ProtegeOWLOntologyManager.java:139) at org.protege.owlapi.model.ProtegeOWLOntologyManager.callWithWriteLock(ProtegeOWLOntologyManager.java:180) at org.protege.owlapi.model.ProtegeOWLOntologyManager.callWithWriteLockUnchecked(ProtegeOWLOntologyManager.java:190) ... 58 more Caused by: org.semanticweb.owlapi.model.OWLOntologyRenameException: Could not rename ontology. An ontology with this ID already exists: <http://ecoinformatics.org/oboe/oboe.1.0/oboe.owl> at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.checkForOntologyIDChange(OWLOntologyManagerImpl.java:476) at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.enactChangeApplication(OWLOntologyManagerImpl.java:371) at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.applyChanges(OWLOntologyManagerImpl.java:391) at org.protege.owlapi.model.ProtegeOWLOntologyManager.applyChangesSuper(ProtegeOWLOntologyManager.java:146) at org.protege.owlapi.model.ProtegeOWLOntologyManager.access$300(ProtegeOWLOntologyManager.java:26)
at org.protege.owlapi.model.ProtegeOWLOntologyManager$4.call(ProtegeOWLOntologyManager.java:153) at org.protege.owlapi.model.ProtegeOWLOntologyManager$4.call(ProtegeOWLOntologyManager.java:152)
at org.protege.owlapi.model.ProtegeOWLOntologyManager.callWithWriteLock(ProtegeOWLOntologyManager.java:180)
at org.protege.owlapi.model.ProtegeOWLOntologyManager.callWithWriteLockUnchecked(ProtegeOWLOntologyManager.java:190)
... 66 more
java.lang.RuntimeException: java.lang.RuntimeException: org.semanticweb.owlapi.model.OWLOntologyRenameException: Could not rename ontology. An ontology with this ID already exists: <http://ecoinformatics.org/oboe/oboe.1.0/oboe.owl>
at org.protege.owlapi.model.ProtegeOWLOntologyManager.callWithWriteLockUnchecked(ProtegeOWLOntologyManager.java:193)
at org.protege.owlapi.model.ProtegeOWLOntologyManager.applyChange(ProtegeOWLOntologyManager.java:137)
at org.coode.owlapi.rdfxml.parser.OWLRDFConsumer.applyChange(OWLRDFConsumer.java:826)
at org.coode.owlapi.rdfxml.parser.TypeOntologyHandler.handleTriple(TypeOntologyHandler.java:29)
at org.coode.owlapi.rdfxml.parser.OWLRDFConsumer.handleStreaming(OWLRDFConsumer.java:1563)
at org.coode.owlapi.rdfxml.parser.OWLRDFConsumer.statementWithResourceValue(OWLRDFConsumer.java:1538)
at org.semanticweb.owlapi.rdf.syntax.RDFParser.statementWithResourceValue(RDFParser.java:556)
at org.semanticweb.owlapi.rdf.syntax.RDFParser$NodeElement.startElement(RDFParser.java:848) at org.semanticweb.owlapi.rdf.syntax.RDFParser$NodeElementList.startElement(RDFParser.java:777)
at org.semanticweb.owlapi.rdf.syntax.RDFParser.startElement(RDFParser.java:261)
at org.coode.owlapi.rdfxml.parser.RDFXMLParser$1.startElement(RDFXMLParser.java:52) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:501) at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java:767) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:400) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2755)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) at javax.xml.parsers.SAXParser.parse(SAXParser.java:395) at org.semanticweb.owlapi.rdf.syntax.RDFParser.parse(RDFParser.java:153) at org.coode.owlapi.rdfxml.parser.RDFXMLParser.parse(RDFXMLParser.java:80) at uk.ac.manchester.cs.owl.owlapi.ParsableOWLOntologyFactory.loadOWLOntology(ParsableOWLOntologyFactory.java:165) at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:687) at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntologyFromOntologyDocument(OWLOntologyManagerImpl.java:644) at edu.gonzaga.oboe.OBOETreeHierarchy.importDifferentOboe(OBOETreeHierarchy.java:217) at edu.gonzaga.oboe.OBOETreeHierarchy.access$3(OBOETreeHierarchy.java:211)
at edu.gonzaga.oboe.OBOETreeHierarchy$2.actionPerformed(OBOETreeHierarchy.java:169) at org.protege.editor.core.ui.view.ViewActionAdapter.actionPerformed(ViewActionAdapter.java:52) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236)
at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:272)
at java.awt.Component.processMouseEvent(Component.java:6267)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
at java.awt.Component.processEvent(Component.java:6032)
at java.awt.Container.processEvent(Container.java:2041)
at java.awt.Component.dispatchEventImpl(Component.java:4630)
at java.awt.Container.dispatchEventImpl(Container.java:2099)
at java.awt.Component.dispatchEvent(Component.java:4460)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4577)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4238)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168)
at java.awt.Container.dispatchEventImpl(Container.java:2085)
at java.awt.Window.dispatchEventImpl(Window.java:2478)
at java.awt.Component.dispatchEvent(Component.java:4460)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
Caused by: java.lang.RuntimeException: org.semanticweb.owlapi.model.OWLOntologyRenameException: Could not rename ontology. An ontology with this ID already exists: <http://ecoinformatics.org/oboe/oboe.1.0/oboe.owl>
at org.protege.owlapi.model.ProtegeOWLOntologyManager.callWithWriteLockUnchecked(ProtegeOWLOntologyManager.java:193)
at org.protege.owlapi.model.ProtegeOWLOntologyManager.applyChanges(ProtegeOWLOntologyManager.java:150)
at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.applyChange(OWLOntologyManagerImpl.java:427)
at org.protege.owlapi.model.ProtegeOWLOntologyManager.applyChangeSuper(ProtegeOWLOntologyManager.java:132)
at org.protege.owlapi.model.ProtegeOWLOntologyManager.access$200(ProtegeOWLOntologyManager.java:26) at org.protege.owlapi.model.ProtegeOWLOntologyManager$3.call(ProtegeOWLOntologyManager.java:140)
at org.protege.owlapi.model.ProtegeOWLOntologyManager$3.call(ProtegeOWLOntologyManager.java:139) at org.protege.owlapi.model.ProtegeOWLOntologyManager.callWithWriteLock(ProtegeOWLOntologyManager.java:180) at org.protege.owlapi.model.ProtegeOWLOntologyManager.callWithWriteLockUnchecked(ProtegeOWLOntologyManager.java:190) ... 58 more Caused by: org.semanticweb.owlapi.model.OWLOntologyRenameException: Could not rename ontology. An ontology with this ID already exists: <http://ecoinformatics.org/oboe/oboe.1.0/oboe.owl> at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.checkForOntologyIDChange(OWLOntologyManagerImpl.java:476) at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.enactChangeApplication(OWLOntologyManagerImpl.java:371) at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.applyChanges(OWLOntologyManagerImpl.java:391) at org.protege.owlapi.model.ProtegeOWLOntologyManager.applyChangesSuper(ProtegeOWLOntologyManager.java:146) at org.protege.owlapi.model.ProtegeOWLOntologyManager.access$300(ProtegeOWLOntologyManager.java:26)
at org.protege.owlapi.model.ProtegeOWLOntologyManager$4.call(ProtegeOWLOntologyManager.java:153) at org.protege.owlapi.model.ProtegeOWLOntologyManager$4.call(ProtegeOWLOntologyManager.java:152)
at org.protege.owlapi.model.ProtegeOWLOntologyManager.callWithWriteLock(ProtegeOWLOntologyManager.java:180)
at org.protege.owlapi.model.ProtegeOWLOntologyManager.callWithWriteLockUnchecked(ProtegeOWLOntologyManager.java:190)
... 66 more

--- On Thu, 7/21/11, Wesley Saunders <[hidden email]> wrote:

From: Wesley Saunders <[hidden email]>
Subject: [p4-feedback] Custom import ontology button problem
To: "protege" <[hidden email]>
Date: Thursday, July 21, 2011, 1:22 PM

 Hello all,Ive been really struggling with an import ontology button im working on...For the plug in im building it is basically a custom interface allowing users to describe a specific ontology. Since every ontology is built on the same one i import that by default, however  the default ontology can change (The url of it)So i am adding a quick fix button that allows the user to import what ever ontology they want. to by plug in. And everything works fine unlessThe users imports an ontologydeletes itand then re imports itI get an error that says naming conflict etc. However protege seems to handle what ever conflict when you use their built in features. My question is what do i need to do  to handle the conflict, or where are the protege files that handle it. ive been loking but cant find anything...Anyway great to be working on protege again! hopefully someone can help me out!W

-----Inline Attachment Follows-----

_______________________________________________
p4-feedback mailing list
p4-feedback@...
https://mailman.stanford.edu/mailman/listinfo/p4-feedback

_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback
Open this post in threaded view
|

## datatype and annotation property ambiguity (FOAF test case)

 In reply to this post by Wesley Saunders I just came upon an inconsistency and roundtrippring problem with datatype- and annotation properties, which can be exemplified by using FOAF. Here are the details: Protege ver. 4.1.0 b235 Steps: 1)load the FOAF ontology from http://xmlns.com/foaf/spec/index.rdf into Protege 2)create a individual and assign datatype properties foaf:name and foaf:surname with some literal values 3)Save the ontology in a)RDF/XML b)OWL/XML 4)Load back the RDF/XML: foaf:name is now an annotation and foaf:surname remains datatype 5)Load back the OWL/XML: foaf:name and foaf:surname are both datatype assertions Now, looking closely on the FOAF ontology, it turns out that foaf:name is declared as an owl datatype property but is also made a subProperty of rdfs:label which by spec is a default annotation property. So, what should be normative behaviour in this case? (4) or (5)? My view is (5) since that is what the user intended anyway. Or is there none? And what about the roundtrip? Best, Dimitrios _______________________________________________ p4-feedback mailing list [hidden email] https://mailman.stanford.edu/mailman/listinfo/p4-feedback
Open this post in threaded view
|

## Re: datatype and annotation property ambiguity (FOAF test case)

 Now, looking closely on the FOAF ontology, it turns out that foaf:name is declared as an owl datatype property but is also made a subProperty of rdfs:label which by spec is a default annotation property. So, what should be normative behaviour in this case? (4) or (5)? My view is (5) since that is what the user intended anyway. Or is there none? And what about the roundtrip? You gave a very nice description of the problem.  Unfortunately this is a somewhat depressing topic.  Simply put the foaf ontology is not valid in OWL 2.   Some of the issues with foaf as an OWL 2 ontology are particularly nasty because they create problems at parse time.  You can of course always use the vocabulary without importing the ontology.  But probably the right thing to happen is to use an owl 2 (dl) version of foaf.  There are some references to this on the web but I am not sure if one of these references is definitive. So first of all, I think that a strictly compliant OWL 2 parser should not be able to parse the foaf ontology.  I think that there is no annotation declaration property declaration for name but there is a sub annotation property axiom. The specification of an OWL 2 RDF parser [1] states that in order to parse an sub-annotation property axiom the sub annotation and super annotation properties must be declared.  You can see this in the attachment (DeclarationsAreRequired).  The little AP(*:x)\neq\epsilon indicates that *:x must be declared.  The specification of an rdf parser is rather draconian about this situation - it indicates that such an ontology should be rejected.  I have analyzed these types of situations before [2]. But the OWL api tries to be more friendly about this and tries its best to parse the ontology.  As a result it gets a property that is both an annotation and a data property.   But the OWL 2 specification states No IRI I is declared in Ax as being of more than one type of property; that is, no I is declared in Ax to be both object and data, object and annotation, or data and annotation property. The reason for this constraint is essentially because the RDF syntax is ambiguous in these cases.  The OWL 2 specification says: These constraints are used for disambiguating the types of IRIs when reading ontologies from external transfer syntaxes. 4)Load back the RDF/XML: foaf:name is now an annotation and foaf:surname remains datatype 5)Load back the OWL/XML: foaf:name and foaf:surname are both datatype assertions  I think that what is happening is that the annotation/data property pun leads to ambiguities in the RDF/XML syntax and which can thus be parsed in more than one way.  In the OWL/XML syntax, the axioms are unambiguous in spite of the annotation/data property pun. So, what should be normative behaviour in this case? So I think that - unfortunately - the normative behavior in this case is that foaf should simply be rejected. -Timothy [1] http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Parsing_of_Axioms [2] http://protegewiki.stanford.edu/wiki/OWL2RDFParserDeclarationRequirement  On 07/22/2011 08:10 PM, Dimitrios Koutsomitropoulos wrote: I just came upon an inconsistency and roundtrippring problem with datatype- and annotation properties, which can be exemplified by using FOAF. Here are the details: Protege ver. 4.1.0 b235 Steps: 1)load the FOAF ontology from http://xmlns.com/foaf/spec/index.rdf into Protege 2)create a individual and assign datatype properties foaf:name and foaf:surname with some literal values 3)Save the ontology in a)RDF/XML b)OWL/XML 4)Load back the RDF/XML: foaf:name is now an annotation and foaf:surname remains datatype 5)Load back the OWL/XML: foaf:name and foaf:surname are both datatype assertions Now, looking closely on the FOAF ontology, it turns out that foaf:name is declared as an owl datatype property but is also made a subProperty of rdfs:label which by spec is a default annotation property. So, what should be normative behaviour in this case? (4) or (5)? My view is (5) since that is what the user intended anyway. Or is there none? And what about the roundtrip? Best, Dimitrios _______________________________________________ p4-feedback mailing list [hidden email] https://mailman.stanford.edu/mailman/listinfo/p4-feedback  _______________________________________________ p4-feedback mailing list [hidden email] https://mailman.stanford.edu/mailman/listinfo/p4-feedback DeclarationsAreRequired.png (9K) Download Attachment
Open this post in threaded view
|

## Re: datatype and annotation property ambiguity (FOAF test case)

Open this post in threaded view
|

## Re: datatype and annotation property ambiguity (FOAF test case)

Open this post in threaded view
|

## Re: datatype and annotation property ambiguity (FOAF test case)

 >Also, it appears to me that, all of a sudden, later Protege versions seem to give precedence to annotation properties, even in cases when it is not strictly necessary (does it make an effort to maintain decidability?). > E.g. in the FOAF case above (step 4) the parser could have safely taken the other path and keep the datatype assertion (as it actually does in the XML case), rather than dropping it in favor of the annotation. Why is this behavior? OK, I think I found out what is the cause of this. It is actually the same problem on the reverse: https://mailman.stanford.edu/pipermail/p4-feedback/2011-February/003558.htmlNow, the API resolves this issue by giving precedence to the annotation...Still however this is inconsistent behaviour (what if the user meant a datatype assertion instead?). The issue remains open btw. _______________________________________________ p4-feedback mailing list [hidden email] https://mailman.stanford.edu/mailman/listinfo/p4-feedback
Open this post in threaded view
|

## Re: datatype and annotation property ambiguity (FOAF test case)

 Agreed, and I think protege should implement the standard by default. If there is a less strict but possibly buggy mode (I.e. the current behavior) it can be offered to the user in the dialog that tells them that the ontology is not OWL DL and should be rejected (assuming protege is specified to only operate correctly for OWL DL). I'm pretty sure that this issue has been noted before. From the point of view of purity, I see that this is a very clean position to push.   It makes me somewhat nervous though.  For Protege 3 we have alway gone to a lot of trouble to try to parse ontologies even when they are problematic.   I suspect with the OWL tools out there the strict position will create a lot of trouble.    In any case - for the moment - this may be an issue for the OWL api developers.  The OWL api loads the foaf even in strict mode. E.g. in the FOAF case above (step 4) the parser could have safely taken the other path and keep the datatype assertion (as it actually does in the XML case), rather than dropping it in favor of the annotation. Why is this behavior?  The parser has no way of determining whether the original axiom was a datatype assertion or an annotation assertion.  They look identical.  So in my test it the triple  "Timothy"  could be either an annotation assertion or a datatype assertion. The reason things are different in the OWL/XML case is that it doesn't have this problem.  If you look at the axiom it is clear what it means:  Timothy  In a very real sense this whole issue is an rdf serialization problem. What about the so-called "OWL 2 Full" case? Shouldn't we expect Protege 4 to work (not to reason) with such ontologies at all?  OWL 2 Full is essentially a different language with a different syntax (rdf) and different semantics than OWL 2.  The toolsets are also going to be different.  The OWL api parser attempts to deal with rdf files by parsing them into the OWL 2 language (as specified in [1]).  I suspect that the only way to deal with OWL 2 Full is to base your work on rdf. -Timothy [1] http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/ _______________________________________________ p4-feedback mailing list [hidden email] https://mailman.stanford.edu/mailman/listinfo/p4-feedback
Open this post in threaded view
|

## Re: datatype and annotation property ambiguity (FOAF test case)

 On Sat, Jul 23, 2011 at 10:12 PM, Timothy Redmond wrote: Agreed, and I think protege should implement the standard by default. If there is a less strict but possibly buggy mode (I.e. the current behavior) it can be offered to the user in the dialog that tells them that the ontology is not OWL DL and should be rejected (assuming protege is specified to only operate correctly for OWL DL). I'm pretty sure that this issue has been noted before. From the point of view of purity, I see that this is a very clean position to push.   It makes me somewhat nervous though.  For Protege 3 we have always gone to a lot of trouble to try to parse ontologies even when they are problematic.Yes, and how much time did I and other have to spend debugging and notifying you when the trouble you took led to corrupt or incorrect serializations?   I suspect with the OWL tools out there the strict position will create a lot of trouble.    I'm not sure what kinds of trouble you are alluding tool. But I will point out that editing tools have special responsibilities compared to other tools. The standard for editors, for instance, is to *never* lose data. In any case, it's not purity I'm concerned with. It's data corruption and predictability. If the tools do not act predictable, and that predictability is not documented, then there will be silent corruption only noticed by experts when it is too late. I am not proposing that protege act obnoxiously. I'm simply suggesting that if and when it goes outside the OWL specification - the best documentation we have for the language - that the user is notified, informed of the possible consequences of their action, and given whatever choices are possible. From a use interface point of view there are several choices - one can offer to never mention such issues after the first time, or ask each time, or remember choices for specific ontologies. But the default should be that before the tool does something not mandated by the specification the user is notified that something is out of the ordinary and given a choice of what they want to do.   In any case - for the moment - this may be an issue for the OWL api developers.  The OWL api loads the foaf even in strict mode.Could you submit a bug report on that if you haven't already, please?Resolution of this bug shouldn't be a blocker on resolving what Protege's policy on this matter will be in the future. Best,-Alan E.g. in the FOAF case above (step 4) the parser could have safely taken the other path and keep the datatype assertion (as it actually does in the XML case), rather than dropping it in favor of the annotation. Why is this behavior?  The parser has no way of determining whether the original axiom was a datatype assertion or an annotation assertion.  They look identical.  So in my test it the triple  "Timothy"  could be either an annotation assertion or a datatype assertion. The reason things are different in the OWL/XML case is that it doesn't have this problem.  If you look at the axiom it is clear what it means:  Timothy  In a very real sense this whole issue is an rdf serialization problem. What about the so-called "OWL 2 Full" case? Shouldn't we expect Protege 4 to work (not to reason) with such ontologies at all?  OWL 2 Full is essentially a different language with a different syntax (rdf) and different semantics than OWL 2.  The toolsets are also going to be different.  The OWL api parser attempts to deal with rdf files by parsing them into the OWL 2 language (as specified in [1]).  I suspect that the only way to deal with OWL 2 Full is to base your work on rdf. -Timothy [1] http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/ _______________________________________________ p4-feedback mailing list [hidden email] https://mailman.stanford.edu/mailman/listinfo/p4-feedback _______________________________________________ p4-feedback mailing list [hidden email] https://mailman.stanford.edu/mailman/listinfo/p4-feedback
Open this post in threaded view
|

## Re: datatype and annotation property ambiguity (FOAF test case)

 It turns out that there is already a bug report out for this [1]. -Timothy [1] https://sourceforge.net/tracker/?func=detail&aid=3015732&group_id=90989&atid=595534 On 07/23/2011 08:06 PM, Alan Ruttenberg wrote: On Sat, Jul 23, 2011 at 10:12 PM, Timothy Redmond wrote: Agreed, and I think protege should implement the standard by default. If there is a less strict but possibly buggy mode (I.e. the current behavior) it can be offered to the user in the dialog that tells them that the ontology is not OWL DL and should be rejected (assuming protege is specified to only operate correctly for OWL DL). I'm pretty sure that this issue has been noted before. From the point of view of purity, I see that this is a very clean position to push.   It makes me somewhat nervous though.  For Protege 3 we have always gone to a lot of trouble to try to parse ontologies even when they are problematic. Yes, and how much time did I and other have to spend debugging and notifying you when the trouble you took led to corrupt or incorrect serializations?   I suspect with the OWL tools out there the strict position will create a lot of trouble.    I'm not sure what kinds of trouble you are alluding tool. But I will point out that editing tools have special responsibilities compared to other tools. The standard for editors, for instance, is to *never* lose data. In any case, it's not purity I'm concerned with. It's data corruption and predictability. If the tools do not act predictable, and that predictability is not documented, then there will be silent corruption only noticed by experts when it is too late. I am not proposing that protege act obnoxiously. I'm simply suggesting that if and when it goes outside the OWL specification - the best documentation we have for the language - that the user is notified, informed of the possible consequences of their action, and given whatever choices are possible. From a use interface point of view there are several choices - one can offer to never mention such issues after the first time, or ask each time, or remember choices for specific ontologies. But the default should be that before the tool does something not mandated by the specification the user is notified that something is out of the ordinary and given a choice of what they want to do.   In any case - for the moment - this may be an issue for the OWL api developers.  The OWL api loads the foaf even in strict mode. Could you submit a bug report on that if you haven't already, please? Resolution of this bug shouldn't be a blocker on resolving what Protege's policy on this matter will be in the future. Best, -Alan E.g. in the FOAF case above (step 4) the parser could have safely taken the other path and keep the datatype assertion (as it actually does in the XML case), rather than dropping it in favor of the annotation. Why is this behavior?  The parser has no way of determining whether the original axiom was a datatype assertion or an annotation assertion.  They look identical.  So in my test it the triple  "Timothy"  could be either an annotation assertion or a datatype assertion. The reason things are different in the OWL/XML case is that it doesn't have this problem.  If you look at the axiom it is clear what it means:  Timothy  In a very real sense this whole issue is an rdf serialization problem. What about the so-called "OWL 2 Full" case? Shouldn't we expect Protege 4 to work (not to reason) with such ontologies at all?  OWL 2 Full is essentially a different language with a different syntax (rdf) and different semantics than OWL 2.  The toolsets are also going to be different.  The OWL api parser attempts to deal with rdf files by parsing them into the OWL 2 language (as specified in [1]).  I suspect that the only way to deal with OWL 2 Full is to base your work on rdf. -Timothy [1] http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/ _______________________________________________ p4-feedback mailing list [hidden email] https://mailman.stanford.edu/mailman/listinfo/p4-feedback  _______________________________________________ p4-feedback mailing list [hidden email] https://mailman.stanford.edu/mailman/listinfo/p4-feedback  _______________________________________________ p4-feedback mailing list [hidden email] https://mailman.stanford.edu/mailman/listinfo/p4-feedback
 On 07/23/2011 08:38 PM, Timothy Redmond wrote: It turns out that there is already a bug report out for this [1]. or actually a better match is [2]. -Timothy [2] https://sourceforge.net/tracker/?func=detail&aid=3000249&group_id=90989&atid=595534 -Timothy [1] https://sourceforge.net/tracker/?func=detail&aid=3015732&group_id=90989&atid=595534 On 07/23/2011 08:06 PM, Alan Ruttenberg wrote: On Sat, Jul 23, 2011 at 10:12 PM, Timothy Redmond wrote: Agreed, and I think protege should implement the standard by default. If there is a less strict but possibly buggy mode (I.e. the current behavior) it can be offered to the user in the dialog that tells them that the ontology is not OWL DL and should be rejected (assuming protege is specified to only operate correctly for OWL DL). I'm pretty sure that this issue has been noted before. From the point of view of purity, I see that this is a very clean position to push.   It makes me somewhat nervous though.  For Protege 3 we have always gone to a lot of trouble to try to parse ontologies even when they are problematic. Yes, and how much time did I and other have to spend debugging and notifying you when the trouble you took led to corrupt or incorrect serializations?   I suspect with the OWL tools out there the strict position will create a lot of trouble.    I'm not sure what kinds of trouble you are alluding tool. But I will point out that editing tools have special responsibilities compared to other tools. The standard for editors, for instance, is to *never* lose data. In any case, it's not purity I'm concerned with. It's data corruption and predictability. If the tools do not act predictable, and that predictability is not documented, then there will be silent corruption only noticed by experts when it is too late. I am not proposing that protege act obnoxiously. I'm simply suggesting that if and when it goes outside the OWL specification - the best documentation we have for the language - that the user is notified, informed of the possible consequences of their action, and given whatever choices are possible. From a use interface point of view there are several choices - one can offer to never mention such issues after the first time, or ask each time, or remember choices for specific ontologies. But the default should be that before the tool does something not mandated by the specification the user is notified that something is out of the ordinary and given a choice of what they want to do.   In any case - for the moment - this may be an issue for the OWL api developers.  The OWL api loads the foaf even in strict mode. Could you submit a bug report on that if you haven't already, please? Resolution of this bug shouldn't be a blocker on resolving what Protege's policy on this matter will be in the future. Best, -Alan E.g. in the FOAF case above (step 4) the parser could have safely taken the other path and keep the datatype assertion (as it actually does in the XML case), rather than dropping it in favor of the annotation. Why is this behavior?  The parser has no way of determining whether the original axiom was a datatype assertion or an annotation assertion.  They look identical.  So in my test it the triple  "Timothy"  could be either an annotation assertion or a datatype assertion. The reason things are different in the OWL/XML case is that it doesn't have this problem.  If you look at the axiom it is clear what it means:  Timothy  In a very real sense this whole issue is an rdf serialization problem. What about the so-called "OWL 2 Full" case? Shouldn't we expect Protege 4 to work (not to reason) with such ontologies at all?  OWL 2 Full is essentially a different language with a different syntax (rdf) and different semantics than OWL 2.  The toolsets are also going to be different.  The OWL api parser attempts to deal with rdf files by parsing them into the OWL 2 language (as specified in [1]).  I suspect that the only way to deal with OWL 2 Full is to base your work on rdf. -Timothy [1] http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/ _______________________________________________ p4-feedback mailing list [hidden email] https://mailman.stanford.edu/mailman/listinfo/p4-feedback  _______________________________________________ p4-feedback mailing list [hidden email] https://mailman.stanford.edu/mailman/listinfo/p4-feedback   _______________________________________________ p4-feedback mailing list [hidden email] https://mailman.stanford.edu/mailman/listinfo/p4-feedback  _______________________________________________ p4-feedback mailing list [hidden email] https://mailman.stanford.edu/mailman/listinfo/p4-feedback