[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]