[regrep] comments on the ebXML Registry Profile for OWL

Hi,

Here few comments on OWL Profile v1.2.  

 

Thank you very much to the editors 
of this profile for the really good work!

 

regards,

Ivan

 

 

Editorial (the "->" means 
"change to/action")

 

Line 806 – ClassificatioNode -> 
ClassificationNode

Line 833 – can be important in 
when… -> can be important when…

Line 1151 – "…then then…" -> 
"…then…"

Line 1262 – "…to all of the 
classes involved…" -?> "…to all classes 
involved…"

Line 1285 –  line duplication -> to be 
removed

Line 1435 – "…is not be stored…" 
-> "…is not stored…"

Line 1560 – "…Regitsry…" -> 
"Registry…"

Line 1568 – " …MUST be support 
by…" -?> "…MUST be supported by…"

Line 1600 – "<<" -> 
"<"

Line 1721 – "recursicely" -> 
"recursively"

Line 1726 – "SuperClassses" -> 
"SuperClasses"

Line 2610 – "Instances Discovery 
Query" -?> "Intersection Discovery Query"

Line 2616 – "…an intersection two 
classes…" -> "an intersection of two classes"

 

Generic

 

Line 702,… – suggest to change 
"… AssociationType:OWLAssociationTypes:…" 
simply to "…AssociationType:owl:…"  (the same thing for all others 
occurrences)

 

Line 870 – Why we use the 
association for defining "members" of the  registry package? IMO we should use the 
native package registryObjectList for defining objects belonging to the 
collection, as follow:

<rim:RegistryPackage 
id = ${Collection} >

<rim:Slot 
name=urn:oasis:names:tc:ebxmlregrep:profile:webontology:slot:packageType>

<rim:ValueList>

<rim:Value>allDifferent</rim:Value>

</rim:ValueList>

</rim:Slot>

<rim:RegistryObjectList>

<rim:objectRef=${MyCarService} 
/>

<rim:objectRef=${MyFlightService} 
/>

<rim:objectRef=${MyHotelService} 
/>

</rim:RegistryObjectList>

</rim:RegistryPackage>

 

Line 1260/1263 and 1291/1295 – these 
two sentences aren’t really clear in my mind, I don't understand the definition 
and the implication for the registry. Consider revision.

Line 2611/2613 – as Line 1260/1263 
and 1291/1295. 

 

Line 2666 - The lid shouldn't be 
the same that the ID. Also IMO it is not necessary to define the LID as a URN. 
(Maybe that this comment impact also the profile template where we could add 
more suggestions about naming conventions)

 

Structure

 

- Chapter 3 – ebXML Registry 
Overview: this chapter shouldn't be in a profile, if needed it can be a 
reference to another specific document (like the ebRR DPT for example). Also 
section 3.2 is not complete and I don't think that authors of a profile should 
be really involved into the generic overview definition of ebRIM and ebRS. This 
chapter could be an overview or a focus of a specific registry feature if it is 
relevant for the profile (i.e.: a specific registry feature can cover a 
requirement for the profile). 

- Chapter 6 – Discovery 
Profile: A reference between discovery  queries and  theirs canonical query may be 
appreciable 

- Chapter 6 – 
Discovery Profile: IMO it is not necessary to provide an example for each 
defined adhoc query, as they are they don't provide any additional information 
or example they just depict the rim syntax and the only change is the name of 
the parameter and of the query. An example for each query with a substantial 
difference should be enough. 

As result the document can acquire 
more readability. (See the  latest 
 deployment profile template structure for 
example)

- Chapter 7 – Canonical Metadata 
Definition - it can be interesting to provide also attached to the document all 
the canonical Submit Object Request XML instances for the profile (as it is the 
case for our specs). This feature can provide a sort of "profile plug-in for 
registry implementations". In this way users that wish to implement the OWL 
profile, easily could install all required artefacts and the query library for 
their  own  registry  implementation.