OWL2RDFParserDeclarationRequirement - Revision history

Tredmond at 19:47, March 2, 2011

2011-03-02T19:47:39Z

Tredmond at 18:36, March 2, 2011

2011-03-02T18:36:57Z

Tredmond at 18:35, March 2, 2011

2011-03-02T18:35:33Z

Tredmond at 18:29, March 2, 2011

2011-03-02T18:29:36Z

Tredmond at 18:25, March 2, 2011

2011-03-02T18:25:43Z

Tredmond at 18:24, March 2, 2011

2011-03-02T18:24:56Z

Tredmond at 18:12, March 2, 2011

2011-03-02T18:12:29Z

Tredmond: Created page with 'So the primary source is [1]. Here the serialization of OWL 2 into RDF is defined. In fact two mappings are defined, the mapping from OWL 2 into RDF is here [2] and the mapping…'

2011-03-02T18:06:44Z

Created page with 'So the primary source is [1]. Here the serialization of OWL 2 into RDF is defined. In fact two mappings are defined, the mapping from OWL 2 into RDF is here [2] and the mapping…'

New page

So the primary source is [1]. Here the serialization of OWL 2 into RDF is defined. In fact two mappings are defined, the mapping from OWL 2 into RDF is here [2] and the mapping from RDF to OWL 2 is defined here [3]. I will focus on the second of these mappings to show that RDF ontologies with missing entity declarations should not be parsed by an OWL 2 compliant parser.

Let us say that we have an ontology containing a restriction
<pre>
<owl:Restriction>
<owl:onProperty rdf:resource="http://example.org#r"/>
<owl:someValuesFrom rdf:resource="http://example.org#z"/>
</owl:Restriction>
</pre>

There is a subsection inside of [3] that explains how this restriction is supposed to be parsed. I have attached an image showing the part of the table that describes this particular translation. So everything looks good so far but the thing to notice is the OPE(y)\neq\epsilon and the CE(z)\neq\epsilon on the lower left. Essentially these two statements say that y must have an interpretation as an object property expression and z must have an interpretation as a class expression.

So - for simplicity - I will now focus on OPE(y) and try to show that y must either be declared as an object property in the RDF file or must be an inverse. To do this I go back to the top of [3] and start searching for all instances of OPE to see how it is calculated. I have to search through several hits but there are only a couple of places where it is assigned. The first place is in in the Analyzing Declarations section [5]. Here it essentially says that OPE of an IRI is assigned to be the object property with that name if the object property is declared. The way in which the declarations are extracted is defined in the previous section. Thus for OPE of an IRI to be defined there must be an object property declaration for that property.

The second place where OPE is assigned a value is in [6]. In table 11 it is stated that OPE(_:x) is assigned to the object inverse of OPE(*:y) when an inverse property assertion appears in the rdf file. Note here again that there is the little OPE(*:y)\neq\epsilon on the lower right hand side of the table entry. If you continue searching forward for OPE you will find many more hits but nothing more that assigns a value to it.

There is a final statement in the argument. At the very end of section 3 [3] there is a statement that says:
<pre>
At the end of this process, the graph G MUST be empty.
</pre>

The easiest way to find this sentence is to go to the first appendix [7] and scroll up a small bit. This means that all the triples must be accounted for in the parse. This is actually an important requirement because otherwise after a parse and a save some data will be lost.

In a way this is all very clean and mathematically precise. The parse must succeed all the way from the ground up. It doesn't allow for any inference to determine any missing types of resources. It requires that all the resource have types that are declared in the ontology. It is a bit draconian for a practical parser though. I think that the parser should fill in any holes when it can so that user can see the results of the parse. But the tool should also then write the ontology out with all the holes filled so that it now fits the specification.

In the next (much shorter) message I am going to proceed to muddy the waters a bit.

-Timothy

[1] http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/
[2] http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_the_Structural_Specification_to_RDF_Graphs
[3] http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_RDF_Graphs_to_the_Structural_Specification
[4] http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Parsing_of_Expression
[5] http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Analyzing_Declarations
[6] http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Parsing_of_Expressions
[7] http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Appendix:_Change_Log_.28Informative.29

← Older revision		Revision as of 19:47, March 2, 2011
Line 39:		Line 39:
	The problem with this ontology is that the declarations of the property r and classes y and z are missing (they are commented out). If the declarations of the property, r, and the classes, y and z, are uncommented then the ontology parses with no problem. To simplify the discussion, I will focus on the declaration of the property r.		The problem with this ontology is that the declarations of the property r and classes y and z are missing (they are commented out). If the declarations of the property, r, and the classes, y and z, are uncommented then the ontology parses with no problem. To simplify the discussion, I will focus on the declaration of the property r.

−	The OWL 2 specifications contain a fairly [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/ comprehensive specification] of how OWL 2 ontologies should be ~~serialized to RDF and how RDF should be parsed to be OWL. This specification contains a~~ [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_the_Structural_Specification_to_RDF_Graphs ~~section] describing how OWL 2 should be~~ serialized ~~into~~ RDF and a [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_RDF_Graphs_to_the_Structural_Specification ~~separate section] describing how~~ RDF should be parsed ~~into an~~ OWL ~~2 specification~~. I will focus on the [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_RDF_Graphs_to_the_Structural_Specification second specification] for the purposes of this note.	+	The OWL 2 specifications contain a fairly [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/ comprehensive specification] of how OWL 2 ontologies should be [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_the_Structural_Specification_to_RDF_Graphs serialized to RDF] and how [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_RDF_Graphs_to_the_Structural_Specification RDF should be parsed to be OWL]. I will focus on the [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_RDF_Graphs_to_the_Structural_Specification second specification] for the purposes of this note.

@@ Line 54: / Line 54: @@
 So everything looks good so far but the thing to notice is the OPE(y)\neq\epsilon and the CE(z)\neq\epsilon on the lower left.  Essentially these two statements say that y must have an interpretation as an object property expression and z must have an interpretation as a class expression.
-So - for simplicity - I will now focus on OPE(y) and try to show that y must either be declared as an object property in the RDF file or must be an inverse.  To do this I go back to the top of [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_RDF_Graphs_to_the_Structural_Specification the parser specification] and start searching for all instances of OPE to see how it is calculated.  I have to search through several hits but there are only a couple of places where it is assigned.  The first place is in in the [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Analyzing_Declarations Analyzing Declarations section].  Here it essentially says that OPE of an IRI is assigned to be the object property with that name if the object property is declared.  The way in which the declarations are extracted is defined in the previous section.  Thus for OPE of an IRI to be defined there must be an object property declaration for that property.
+So - for simplicity - I will now focus on OPE(y) and try to show that y must either be declared as an object property in the RDF file or must be an inverse.  To do this I go back to the top of [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_RDF_Graphs_to_the_Structural_Specification the parser specification] and start searching for all instances of OPE to see how it is calculated.  I have to search through several hits but there are only a couple of places where it is assigned.  The first place is in in the [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Analyzing_Declarations Analyzing Declarations section].  Table 9 essentially says that OPE of an IRI is assigned to be the object property with that name if the object property is declared.  The way in which the declarations are extracted is defined in the previous section.  Thus for OPE of an IRI to be defined there must be an object property declaration for that property.
 The second place where OPE is assigned a value is in [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Parsing_of_Expressions a section] describing how property expressions should be parsed.  In table 11 it is stated that OPE(_:x) is assigned to the object inverse of OPE(*:y) when an inverse property assertion appears in the rdf file.  Note here again that there is the little OPE(*:y)\neq\epsilon on the lower right hand side of the table entry.  If you continue searching forward for OPE you will find many more hits but nothing more that assigns a value to it.

@@ Line 50: / Line 50: @@
 </pre>
-There is a [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Parsing_of_Expressions subsection] inside of [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_RDF_Graphs_to_the_Structural_Specification the parser specification] that explains how this restriction is supposed to be parsed.  I have attached an image showing the part of the table that describes this particular translation.  So everything looks good so far but the thing to notice is the OPE(y)\neq\epsilon and the CE(z)\neq\epsilon on the lower left.  Essentially these two statements say that y must have an interpretation as an object property expression and z must have an interpretation as a class expression.
+There is a [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Parsing_of_Expressions subsection] inside of [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_RDF_Graphs_to_the_Structural_Specification the parser specification] that explains how this restriction is supposed to be parsed.  Here is a screenshot showing the relevant specification from table 13:
 So - for simplicity - I will now focus on OPE(y) and try to show that y must either be declared as an object property in the RDF file or must be an inverse.  To do this I go back to the top of [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_RDF_Graphs_to_the_Structural_Specification the parser specification] and start searching for all instances of OPE to see how it is calculated.  I have to search through several hits but there are only a couple of places where it is assigned.  The first place is in in the [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Analyzing_Declarations Analyzing Declarations section].  Here it essentially says that OPE of an IRI is assigned to be the object property with that name if the object property is declared.  The way in which the declarations are extracted is defined in the previous section.  Thus for OPE of an IRI to be defined there must be an object property declaration for that property.

@@ Line 50: / Line 50: @@
 </pre>
-There is a [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Parsing_of_Expression subsection] inside of [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_RDF_Graphs_to_the_Structural_Specification the parser specification] that explains how this restriction is supposed to be parsed.  I have attached an image showing the part of the table that describes this particular translation.  So everything looks good so far but the thing to notice is the OPE(y)\neq\epsilon and the CE(z)\neq\epsilon on the lower left.  Essentially these two statements say that y must have an interpretation as an object property expression and z must have an interpretation as a class expression.
+There is a [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Parsing_of_Expressions subsection] inside of [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_RDF_Graphs_to_the_Structural_Specification the parser specification] that explains how this restriction is supposed to be parsed.  I have attached an image showing the part of the table that describes this particular translation.  So everything looks good so far but the thing to notice is the OPE(y)\neq\epsilon and the CE(z)\neq\epsilon on the lower left.  Essentially these two statements say that y must have an interpretation as an object property expression and z must have an interpretation as a class expression.
 So - for simplicity - I will now focus on OPE(y) and try to show that y must either be declared as an object property in the RDF file or must be an inverse.  To do this I go back to the top of [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_RDF_Graphs_to_the_Structural_Specification the parser specification] and start searching for all instances of OPE to see how it is calculated.  I have to search through several hits but there are only a couple of places where it is assigned.  The first place is in in the [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Analyzing_Declarations Analyzing Declarations section].  Here it essentially says that OPE of an IRI is assigned to be the object property with that name if the object property is declared.  The way in which the declarations are extracted is defined in the previous section.  Thus for OPE of an IRI to be defined there must be an object property declaration for that property.

@@ Line 1: / Line 1: @@
 It turns out that the [http://www.w3.org/2007/OWL/wiki/OWL_Working_Group OWL 2 specifications] contain a very detailed definition of how an RDF serialization of an OWL 2 ontology should be parsed.  I think that for practical purposes this definition is a bit rigid.  It is very useful for an OWL 2 parser to be able to handle files that are slightly malformed.  A good OWL 2 tool can then write the ontology out in a manner that fixes any problems found during the parse.
@@ Line 38: / Line 37: @@
 </rdf:RDF>
 </pre>
-If the declarations of the property, r, and the classes, y and z, are uncommented then the ontology parses with no problem.  To simplify the discussion, I will focus on the declaration of the property r.
+The problem with this ontology is that the declarations of the property r and classes y and z are missing (they are commented out).  If the declarations of the property, r, and the classes, y and z, are uncommented then the ontology parses with no problem.  To simplify the discussion, I will focus on the declaration of the property r.
 The OWL 2 specifications contain a fairly [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/ comprehensive specification] of how OWL 2 ontologies should be serialized to RDF and how RDF should be parsed to be OWL.  This specification contains a [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_the_Structural_Specification_to_RDF_Graphs section] describing how OWL 2 should be serialized into RDF and a [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_RDF_Graphs_to_the_Structural_Specification separate section] describing how RDF should be parsed into an OWL 2 specification.  I will focus on the [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_RDF_Graphs_to_the_Structural_Specification second specification] for the purposes of this note.

@@ Line 1: / Line 1: @@
 In this note, I am going to present the argument that an fully OWL 2 compliant parser should reject the following simple ontology:
 <pre>
@@ Line 37: / Line 40: @@
 If the declarations of the property, r, and the classes, y and z, are uncommented then the ontology parses with no problem.  To simplify the discussion, I will focus on the declaration of the property r.
-The OWL 2 specifications contain a fairly [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/ definition] of how OWL 2 ontologies should be serialized to RDF and how RDF should be parsed to be OWL.
+The OWL 2 specifications contain a fairly [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/ comprehensive specification] of how OWL 2 ontologies should be serialized to RDF and how RDF should be parsed to be OWL.  This specification contains a [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_the_Structural_Specification_to_RDF_Graphs section] describing how OWL 2 should be serialized into RDF and a [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_RDF_Graphs_to_the_Structural_Specification separate section] describing how RDF should be parsed into an OWL 2 specification.  I will focus on the [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_RDF_Graphs_to_the_Structural_Specification second specification] for the purposes of this note.
 Let us say that we have an ontology containing a restriction
@@ Line 49: / Line 51: @@
 </pre>
-There is a subsection inside of [3] that explains how this restriction is supposed to be parsed.  I have attached an image showing the part of the table that describes this particular translation.  So everything looks good so far but the thing to notice is the OPE(y)\neq\epsilon and the CE(z)\neq\epsilon on the lower left.  Essentially these two statements say that y must have an interpretation as an object property expression and z must have an interpretation as a class expression.
+There is a [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Parsing_of_Expression subsection] inside of [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_RDF_Graphs_to_the_Structural_Specification the parser specification] that explains how this restriction is supposed to be parsed.  I have attached an image showing the part of the table that describes this particular translation.  So everything looks good so far but the thing to notice is the OPE(y)\neq\epsilon and the CE(z)\neq\epsilon on the lower left.  Essentially these two statements say that y must have an interpretation as an object property expression and z must have an interpretation as a class expression.
-So - for simplicity - I will now focus on OPE(y) and try to show that y must either be declared as an object property in the RDF file or must be an inverse.  To do this I go back to the top of [3] and start searching for all instances of OPE to see how it is calculated.  I have to search through several hits but there are only a couple of places where it is assigned.  The first place is in in the Analyzing Declarations section [5].  Here it essentially says that OPE of an IRI is assigned to be the object property with that name if the object property is declared.  The way in which the declarations are extracted is defined in the previous section.  Thus for OPE of an IRI to be defined there must be an object property declaration for that property.
+So - for simplicity - I will now focus on OPE(y) and try to show that y must either be declared as an object property in the RDF file or must be an inverse.  To do this I go back to the top of [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_RDF_Graphs_to_the_Structural_Specification the parser specification] and start searching for all instances of OPE to see how it is calculated.  I have to search through several hits but there are only a couple of places where it is assigned.  The first place is in in the [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Analyzing_Declarations Analyzing Declarations section].  Here it essentially says that OPE of an IRI is assigned to be the object property with that name if the object property is declared.  The way in which the declarations are extracted is defined in the previous section.  Thus for OPE of an IRI to be defined there must be an object property declaration for that property.
-The second place where OPE is assigned a value is in [6].  In table 11 it is stated that OPE(_:x) is assigned to the object inverse of OPE(*:y) when an inverse property assertion appears in the rdf file.  Note here again that there is the little OPE(*:y)\neq\epsilon on the lower right hand side of the table entry.  If you continue searching forward for OPE you will find many more hits but nothing more that assigns a value to it.
+The second place where OPE is assigned a value is in [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Parsing_of_Expressions a section] describing how property expressions should be parsed.  In table 11 it is stated that OPE(_:x) is assigned to the object inverse of OPE(*:y) when an inverse property assertion appears in the rdf file.  Note here again that there is the little OPE(*:y)\neq\epsilon on the lower right hand side of the table entry.  If you continue searching forward for OPE you will find many more hits but nothing more that assigns a value to it.
-There is a final statement in the argument.  At the very end of section 3 [3] there is a statement that says:
+There is a final statement in the argument.  At the very end of [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Mapping_from_RDF_Graphs_to_the_Structural_Specification section 3] there is a statement that says:
 <pre>
      At the end of this process, the graph G MUST be empty.
 </pre>
-The easiest way to find this sentence is to go to the first appendix [7] and scroll up a small bit.  This means that all the triples must be accounted for in the parse.  This is actually an important requirement because otherwise after a parse and a save some data will be lost.
+The easiest way to find this sentence is to go to the [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Appendix:_Change_Log_.28Informative.29 first appendix] and scroll up a small bit.  This means that all the triples must be accounted for in the parse.  This is actually an important requirement because otherwise after a parse and a save some data will be lost.
 In a way this is all very clean and mathematically precise.  The parse must succeed all the way from the ground up.   It doesn't allow for any inference to determine any missing types of resources.  It requires that all the resource have types that are declared in the ontology.  It is a bit draconian for a practical parser though.  I think that the parser should fill in any holes when it can so that user can see the results of the parse.  But the tool should also then write the ontology out with all the holes filled so that it now fits the specification.

← Older revision		Revision as of 18:12, March 2, 2011
Line 1:		Line 1:
		+	In this note, I am going to present the argument that an fully OWL 2 compliant parser should reject the following simple ontology:
		+	<pre>
		+	<?xml version='1.0' encoding='UTF-8'?>
		+	<!DOCTYPE rdf:RDF [
		+	<!ENTITY owl 'http://www.w3.org/2002/07/owl#'>
		+	<!ENTITY rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
		+	]>
		+
		+	<rdf:RDF
		+	xmlns:owl="&owl;"
		+	xmlns:rdf="&rdf;"
		+	>
		+	<owl:Ontology rdf:about="http://example.org#test"/>
		+
		+	<!--
		+	<owl:ObjectProperty rdf:about="http://example.org#r"/>
		+	<owl:Class rdf:about="http://example.org#y"/>
		+	<owl:Class rdf:about="http://example.org#z"/>
		+	-->
		+
		+	<owl:Class rdf:about="http://example.org#x">
		+	<owl:equivalentClass>
		+	<owl:Class>
		+	<owl:intersectionOf rdf:parseType="Collection">
		+	<rdf:Description rdf:about="http://example.org#y"/>
		+	<owl:Restriction>
		+	<owl:onProperty rdf:resource="http://example.org#r"/>
		+	<owl:someValuesFrom rdf:resource="http://example.org#z"/>
		+	</owl:Restriction>
		+	</owl:intersectionOf>
		+	</owl:Class>
		+	</owl:equivalentClass>
		+	</owl:Class>
		+
		+	</rdf:RDF>
		+	</pre>
		+	If the declarations of the property, r, and the classes, y and z, are uncommented then the ontology parses with no problem. To simplify the discussion, I will focus on the declaration of the property r.
		+
		+	The OWL 2 specifications contain a fairly [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/ definition] of how OWL 2 ontologies should be serialized to RDF and how RDF should be parsed to be OWL.
		+
	So the primary source is [1]. Here the serialization of OWL 2 into RDF is defined. In fact two mappings are defined, the mapping from OWL 2 into RDF is here [2] and the mapping from RDF to OWL 2 is defined here [3]. I will focus on the second of these mappings to show that RDF ontologies with missing entity declarations should not be parsed by an OWL 2 compliant parser.		So the primary source is [1]. Here the serialization of OWL 2 into RDF is defined. In fact two mappings are defined, the mapping from OWL 2 into RDF is here [2] and the mapping from RDF to OWL 2 is defined here [3]. I will focus on the second of these mappings to show that RDF ontologies with missing entity declarations should not be parsed by an OWL 2 compliant parser.