ebXML Registry Profile for Web Ontology Language - a few comments

["Stojanovic, Nikola" <NStojanovic@gs1us.org>]

Here are some comments on ebXML Registry Profile for Web Ontology Language (OWL), Version 1.1, Draft OASIS Profile, June 13, 2006:

 

 

1. Generic
1. Since this profile is related to ebXML Registry specifications and not to particular implementations, references to freebXML and specific databases should be removed.
2. When possible it would be better to reference ebRIM and not relational tables, e.g., Line 1325 “comment_”.
3. AssociationTypes naming should be consistent and follow ebRIM (UpperCase convention, directionability, …), Also, if “HasProperty” is used for rdf:Property should other owl:XXXProperty be prefixed in the same way -> “Has”?
4. It might be beneficial to try to produce a more precise definition of how certain ebRIM attributes are constructed, e.g., lid, name, ... Very often, e.g., Section 4.8.3 Line 1384 wording says something like “called”, but then example doesn’t show name and puts the value in the id.

 

 

2. Section 1.3 – What would be the status of this Profile in case that ebRS doesn’t change (support for SQL:1999)?

 

 

3. Section 2 – It would be beneficial to state why this profile only addresses OWL Lite.

 

 

4. Section 4.1.1 - It doesn’t say what Classification Scheme these Classification Nodes need to be placed under.

 

 

5. Section 4.1.5: Lines [788-792] – ebXML Registry doesn’t prescribe what kind of “classes / instances” could be stored in the registry; depending on what the class / instance model is, both could be stored into the registry. It is not clear if this Profile is enforcing, recommending, … storing Individuals into a repository.

 

 

6. Section 4.2.2: Lines [803-804] – Similar to the previous comment. In fact, it is valid to have extrinsic objects without repository items.

 

 

7. Section 4.2.4:
1. Line 859 – Should “Example owl:allDifferentFrom” be changed to “Example owl:allDifferent”?
2. Line 861- Suggestion of giving a registry package the name “Collection” might not be the best choice as “Collection” might be overloaded. It looks like name of the package is not relevant as what distinguishes the registry package is its slot “packageType”.
3. Line 862 - “hasMember” should be changed to “HasMember”.

 

 

8. Section 4.6:
1. Line 1260 – should usage of “both” be avoided, i.e., couldn’t intersection be on more then two classes?
2. It seems that another (simpler) mapping for “intersectionOf” could avoid packaging classes into a registry package by associating classification nodes directly.

 

 

9. Section 4.8.3: Line – why the suffix in “seeAlsoExternalLink” (“ExternalLink”)?

 

 

10. Section 4.9: It seems to be somewhat premature to prescribe how XML Schema datatypes are represented in ebXML Registry. This should be defined by the ebXML Registry Profile for XML Schema.

 

 

11. Section 7.1: Line 2687 – Why is the name “label.OWL” and not “OWL”?

 

 

12. Section 7.3 – Subsections with Stored Procedures use a mechanism that is not supported by ebXML Registry and should be taken out.

 

 

 

Regards,

Nikola