LexGrid 2008 and OWL - Revision history

Tredmond: /* Properties with no domains and ranges */

2008-12-06T00:29:41Z

Properties with no domains and ranges

Tredmond: /* Namespace prefix issues */

2008-12-06T00:20:45Z

Namespace prefix issues

Tredmond: /* General notes: */

2008-12-05T23:06:54Z

General notes:

Tredmond: /* General notes: */

2008-12-03T19:12:30Z

General notes:

Tredmond: /* Multiple domains and ranges */

2008-10-20T22:06:10Z

Multiple domains and ranges

Tredmond: /* Multiple domains and ranges */

2008-10-20T22:01:31Z

Multiple domains and ranges

Tredmond: /* Multiple domains and ranges */

2008-10-20T21:58:35Z

Multiple domains and ranges

Hsolbrig: /* Namespaces from the OWL 1.1 perspective */

2008-10-20T18:38:21Z

Namespaces from the OWL 1.1 perspective

Hsolbrig: /* LexGrid importing today */

2008-10-20T18:16:47Z

LexGrid importing today

Hsolbrig: /* Namespace as a unit and ontology as a unit */

2008-10-20T17:58:30Z

Namespace as a unit and ontology as a unit

← Older revision		Revision as of 00:29, 6 December 2008
Line 154:		Line 154:

	However, both datatype properties and object properties can be defined without any domains and ranges (and often are)		However, both datatype properties and object properties can be defined without any domains and ranges (and often are)
		+
		+	-- [[User:Tredmond\|Tredmond]] 00:29, 6 December 2008 (UTC) None of the comments here address the issue that the above mapping from owl to lexgrid appears to be simply wrong. I can't find anything in the [http://www.w3.org/TR/2008/WD-owl2-syntax-20081202/ owl syntax document] that would suggest that such a representation of an owl object property can be faithful. This should either be disavowed or explained.

	--[[User:Hsolbrig\|Hsolbrig]] 09:46, 15 October 2008 (PDT) The existence of domains and ranges or data properties are not a requirement for determining whether a Property is an ObjectProperty or DatatypeProperty - the description in the mapping spreadsheet was misleading.		--[[User:Hsolbrig\|Hsolbrig]] 09:46, 15 October 2008 (PDT) The existence of domains and ranges or data properties are not a requirement for determining whether a Property is an ObjectProperty or DatatypeProperty - the description in the mapping spreadsheet was misleading.

← Older revision		Revision as of 00:20, 6 December 2008
Line 126:		Line 126:

	The equivalent LexGrid rendering of these examples should be:		The equivalent LexGrid rendering of these examples should be:
		+
		+	-- [[User:Tredmond\|Tredmond]] 00:20, 6 December 2008 (UTC) In the [https://cabig-kc.nci.nih.gov/Vocab/KC/images/0/0e/Media-LexGrid_Loader_Mapping.pdf owl to lexgrid spreadsheet] (which may be an obsolete document?), it maps an owl ontology to a coding scheme. The examples above make the coding scheme look more like a set of namespace declarations. Following the [http://www.w3.org/TR/2008/WD-owl2-syntax-20081202/#Functional-Style_Syntax owl specifications] an ontology document consists of
		+	* a set of name space declarations (represented in lexgrid by the coding scheme above?) and
		+	* an ontology
		+	The ontology consists of
		+	* the ontology declarations
		+	* the import statements
		+	* the ontology axioms
		+	If the goal is to capture all of the owl syntax, then I would say that the above addresses the idea that there will be many coding schemes depending on the ontology document. But it does not address the core issues of representing ontologies which are largely represented by sets of axioms. If we can capture this, then we can represent the notion that a entity definition is found in a particular ontology from the import closure because presumably a definition will correspond to a particular type of axiom.

	== Inheritance ==		== Inheritance ==

← Older revision		Revision as of 23:06, 5 December 2008
Line 11:		Line 11:

	-- [[User:Tredmond\|Tredmond]] 19:12, 3 December 2008 (UTC) End Comment		-- [[User:Tredmond\|Tredmond]] 19:12, 3 December 2008 (UTC) End Comment
		+
		+	-- [[User:Tredmond\|Tredmond]] 23:06, 5 December 2008 (UTC) Various people have responded that the lexgrid owl api is not a general purpose owl api like the owlapi. However at the conference call, there was discussion indicating that the lexgrid api is intended to capture all the different parts of the owl syntax. The line was essentially drawn at inference as being something that would not be included. With a disciplined approach based on the owl specifications this should be very possible but it will otherwise be quite difficult to get right.

	= Major features that the model does not seem to handle yet =		= Major features that the model does not seem to handle yet =

← Older revision		Revision as of 19:12, 3 December 2008
Line 4:		Line 4:
	* We understand that while the model seems to account for many OWL features, some critical ones have not been validated yet. We see validation as using either the API or the UI (not necessarily both) to access the stored information. Some of the information has not been stored at all yet. We all agree that validation through the API access (and, preferably, UI) of all features of the model is required to ensure that the information is represented faithfully.		* We understand that while the model seems to account for many OWL features, some critical ones have not been validated yet. We see validation as using either the API or the UI (not necessarily both) to access the stored information. Some of the information has not been stored at all yet. We all agree that validation through the API access (and, preferably, UI) of all features of the model is required to ensure that the information is represented faithfully.

		+	-- [[User:Tredmond\|Tredmond]] 19:12, 3 December 2008 (UTC) I think that one of the issues with this document is that it lacks a statement of purpose. I have heard rumors that the lexgrid owl api is a general purpose owl api like the owlapi. These rumors are suspect and probably have an unacceptably long trail of gossip. Alternatively, parts of this document suggest that all that is needed here is to meet some set of requirements for the Bioportal. These two extremes are very different things.
		+
		+	If the lexgrid api is intended as a general purpose owl api, then I have not yet seen a document that makes me believe that it will be done correctly. Much of what I see on this wiki is suspicious. To really argue that we have a general purpose api, I would want to see some sort of mapping from the owl 1.0 or 2.0 specifications to the implementation. The owl api was a great example of this. The owl 2.0 specifications have changed considerably but the old specification is still [http://www.webont.org/owl/1.1/owl_specification.html here] so this can still be verified. Many important java classes map in an obvious way to the specification. For most of the left hand sides of productions in the OWL 2.0 specification, there was an owl api java class that has corresponding characteristics. In contrast, the Protege 3 owl api shows some of the risks incurred when an owl api is built without a clear mapping to the specification.
		+
		+	At the other extreme, if the lexgrid api is just supposed to be a utility library that provides some useful functionality for Bioportal and other applications, then the bar is set at a very different level. The important thing to determine in this case would be exactly what functionality is supposed to be supported and how this support will be achieved. A clear specification of what the lexgrid library does would be a valuable step in determining that it achieves its functionality.
		+
		+	-- [[User:Tredmond\|Tredmond]] 19:12, 3 December 2008 (UTC) End Comment

	= Major features that the model does not seem to handle yet =		= Major features that the model does not seem to handle yet =

@@ Line 246: / Line 246: @@
 -- [[User:Tredmond|Tredmond]] 21:58, 20 October 2008 (UTC)
-While this is probably not the most critical section, some of this discussion is confusing.  For example there are the following two conflicting quotes: "''Usually the requiried semantics is that of a union.''" and "''To the best of our knowledge, multiple domains and ranges work correctly.  LexGrid doesn't add any semantics beyond what is expressed in the OWL itself.''"  The examples that follow reinforce the confusion by suggesting that for LexGrid multiple domains are viewed as unions.  In owl the assertion that  A is a domain for a property p and B is a domain for a property p is semantically equivalent to the assertion that the intersection of A and B is a domain for the property p.  Another quote that is confusing is the statement that "''Note, that we would also want to get that for any subclass of A (see the inheritance point above).''".  It is true that this is what Protege 3 does in the properties view but this view is confusing.  If A is a domain for the property p and if B is a sub class of A then it '''cannot''' be inferred that B is a domain for the property p.  So for instance, one might know that Person is a domain for the property isSisterOf.  But it would not follow that the subclass Men of Person is a domain for the property isSisterOf.  In fact the correct inference  goes in the exact opposite direction.  If A is a domain for the property p and B is a superclass of A then B is a domain for the property p.  In particular owl:Thing is (semantically) a domain for all properties.  So at issue here is that the owl domain concept does not operate in the way that users familiar with, say, java object inheritance would expect.  A possible point of view is that multiple domains and ranges - in the owl sense - are not supported? Or?
+While this is probably not the most critical section, some of this discussion is confusing.  For example there are the following two conflicting quotes: "''Usually the requiried semantics is that of a union.''" and "''To the best of our knowledge, multiple domains and ranges work correctly.  LexGrid doesn't add any semantics beyond what is expressed in the OWL itself.''"  The examples that follow reinforce the confusion by suggesting that for LexGrid multiple domains are viewed as unions.  In owl the assertion that  A is a domain for a property p and B is a domain for a property p is semantically equivalent to the assertion that the intersection of A and B is a domain for the property p.  Another quote that is confusing is the statement that "''Note, that we would also want to get that for any subclass of A (see the inheritance point above).''".  It is true that this is what Protege 3 does in the properties view but this view is confusing.  If A is a domain for the property p and if B is a sub class of A then it '''cannot''' be inferred that B is a domain for the property p.  So for instance, one might know that Person is a domain for the property isSisterOf.  But it would not follow that the subclass Men of Person is a domain for the property isSisterOf.  In fact the correct inference  goes in the exact opposite direction.  If A is a domain for the property p and B is a superclass of A then B is a domain for the property p.  In particular owl:Thing is (semantically) a domain for all properties.  So at issue here is that the owl domain concept does not operate in the way that users familiar with, say, java object inheritance would expect.  A possible point of view is that multiple domains and ranges - in the owl sense - are not supported? I suspect that correct usage of multiple domains and ranges in owl ontologies is not typical.  Other options?
 = Major features in the model that have not been validated yet =

@@ Line 243: / Line 243: @@
 </lgRel:association>
 </pre>
 = Major features in the model that have not been validated yet =

@@ Line 40: / Line 40: @@
 #* Both http://www.w3.org/2000/01/rdf-schema# and http://www.w3.org/2002/07/owl# make assertions about http://www.w3.org/2000/01/rdf-schema#label
 #* Both http://wiktology.com/rdf/2008/PR-loon-guide/MinnesotaFood# and http://wiktology.com/rdf/2008/PR-loon-guide/AugmentedFood# make assertions about http://www.w3.org/TR/2003/PR-owl-guide-20031209/food#HotDish
-# '''The ontology(s) that ''import'' the resource''' - note that "import" is orthogonal to (2) above.  An ontology can make assertions about any resource, whether or not it imports other resources.
+# '''The ontology(s) that ''import'' the resource''' - note that "import" is orthogonal to (2) above.  What a given ontology imports and what resources it makes assertions about do not necessarily have to be related.
 ==== Basic requirements ====

@@ Line 52: / Line 52: @@
 The LexGrid model was originally designed with the notion that the lexical characteristics of a class, property or individual would be asserted within the same resource that provides the namespace for the resource itself.  The model did, however, allow a resource to make both ObjectProperty and DataProperty assertions about ''any'' resource, independent of where it was declared.
-The latest LexGrid model added the notion of ''Entity.codingSchemeId'', which partially addresses requirement 1 above.  It still assumes that the URI can be partitioned into a namespace and an entry code, which may not always be the case.  We believe, however, that completely opaque resource identifier is something that we may declare to be
+The latest LexGrid model added the notion of ''Entity.codingSchemeId'', which partially addresses requirement 1 above.  It still assumes that the URI can be partitioned into a namespace and an entry code, which may not always be the case.  We believe, however, that completely opaque resource identifier is something that we may declare to be out of scope.
 The treatment of the semantics of CodingScheme inclusion is inconsistent, however.

@@ Line 29: / Line 29: @@
 --[[User:Hsolbrig|Hsolbrig]] 09:38, 15 October 2008 (PDT)
 === Namespace as a unit and ontology as a unit ===
 === Namespace prefix issues ===
 LexGrid supports a local name to URI mapping mechanism that is similar to that used in XML. Using the example above, the resulting codingScheme declaration would be: