OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [regrep] comments on the ebXML Registry Profile for OWL


Here few comments on OWL Profile v1.2.  


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






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"




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:objectRef=${MyCarService} />

<rim:objectRef=${MyFlightService} />

<rim:objectRef=${MyHotelService} />




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)




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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]