Custom import ontology button problem

[Wesley Saunders]

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 unless

The users imports an ontology

deletes it

and then re imports it

I 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

[Wesley Saunders]

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)

at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)

at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)

at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)

at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)

at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)

at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

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

Uncaught Exception in thread AWT-EventQueue-0

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)

at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)

at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)

at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)

at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)

at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)

at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

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 unless

The users imports an ontology

deletes it

and then re imports it

I 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

[kotsomit]

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

[Timothy Redmond]

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

[Alan Ruttenberg-2]

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.

-Alan

On Saturday, July 23, 2011, Timothy Redmond <[hidden email]> wrote:
>
> 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

[kotsomit]

Thank you for your detailed reply. Please see my comments below:

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

OK, but then don't I end up with annotation properties once more?
Even worse, in this case my ontology should be rejected since there will be no declarations for the properties.

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

So it is clear that Protege (through the API) in this case violates the spec and I agree with Alan that it should follow the norm by default (not for any other reason but to let the user know that there is a norm, if there is one that is).

> 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, in accordance to [2], the parser tries to "fill up the holes to fit the spec" but still leaves some holes open to cause this ambiguity...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?


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

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?

Best,
Dimitrios

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

[kotsomit]

>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.html
Now, 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

[Timothy Redmond]

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

<http://xmlns.com/foaf/0.1/i> <http://xmlns.com/foaf/0.1/name> "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:

    <DataPropertyAssertion>
        <DataProperty IRI="name"/>
        <NamedIndividual IRI="i"/>
        <Literal datatypeIRI="&xsd;string">Timothy</Literal>
    </DataPropertyAssertion>

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

[Alan Ruttenberg-2]

On Sat, Jul 23, 2011 at 10:12 PM, Timothy Redmond <[hidden email]> 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

<http://xmlns.com/foaf/0.1/i> <http://xmlns.com/foaf/0.1/name> "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:

    <DataPropertyAssertion>
        <DataProperty IRI="name"/>
        <NamedIndividual IRI="i"/>
        <Literal datatypeIRI="&xsd;string">Timothy</Literal>
    </DataPropertyAssertion>

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

[Timothy Redmond]

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 <[hidden email]> 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

<http://xmlns.com/foaf/0.1/i> <http://xmlns.com/foaf/0.1/name> "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:

    <DataPropertyAssertion>
        <DataProperty IRI="name"/>
        <NamedIndividual IRI="i"/>
        <Literal datatypeIRI="&xsd;string">Timothy</Literal>
    </DataPropertyAssertion>

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

[Timothy Redmond]

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 <[hidden email]> 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

<http://xmlns.com/foaf/0.1/i> <http://xmlns.com/foaf/0.1/name> "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:

    <DataPropertyAssertion>
        <DataProperty IRI="name"/>
        <NamedIndividual IRI="i"/>
        <Literal datatypeIRI="&xsd;string">Timothy</Literal>
    </DataPropertyAssertion>

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

[Timothy Redmond]

There has been a lot of discussion of this issue in several places and I
have some ideas about what can be done about it.  But it occurred to me
that I should add a bug tracker for the item [1].

-Timothy

[1] https://bmir-gforge.stanford.edu/gf/project/owleditor/tracker/?action=TrackerItemEdit&tracker_item_id=3429&start=0



On 07/23/2011 04:59 PM, Dimitrios Koutsomitropoulos wrote:
>> 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.html
> Now, 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

_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback