SUO: Registry etc.
At 10:06 2003-06-06 -0500, Cathy Legg wrote:
>
> Thanks for the reply, Mike. I'm a lot clearer now about what the issue is.
> What if it were made clear in the motion that the registry was not
> itself the SUO but merely a supportive tool for SUO version control?
>
> Cathy.
A registry, like the kind I've outlined for SUO, is not for version control, per se, but serves other purposes. I'm oversimplifying: a registry is (conceptually) a large table with each row as an entry. Certain kinds of registries, e.g., ISO/IEC 11179-3, can support complex structures, including various kinds of relations among the entries (the relationship itself may be an entry). One uses this kind of registry for various purposes:
#1: "I want a standard registry, so I don't have to create my own structures/metadata"
#2: "I want a tool that supports administration of the entries" (note: administration can take many forms, such as quality control, version control, development support)
#3: "I want a tool that allows me to interoperate with other registries"
#4: "I want a tool to support incremental changes to a standard/specification"
- and so on
Like most things, you can optimize them for whatever purpose you want. If the primary goal is merely version control, then Adam's solution (CVS) is probably your best choice. However, CVS doesn't give you an inherent relationship capability. Sure, one can use URIs (via embedding or markup), but that isn't an inherent part of CVS -- that might be a good quality or a bad quality, depending on your design goals.
Anyway, one first decides on the kind of problem they want to solve. In the list above, my reason for suggesting a registry to SUO was primarily to solve #4, and my reason for suggesting 11179-3 is that it addressed #1 above. Certainly, version control and other administrative features are useful, too, but they aren't the prime motivation for using a registry for ontologies.
I believe Matthew West summarized it best:
"A registry is a means to an end, not an end in itself."
Right now, we don't need to concern ourselves with the implementation and layout of our standard (e.g., a registry), we need to be more concerned about the content of what we want to develop -- somewhat like an author's spending time worrying about which word processor to use when there is no book yet to write.
-FF
______________________________________________________________________
Frank Farance, Farance Inc. T: +1 212 486 4700 F: +1 212 759 1605
mailto:frank@farance.com http://farance.com
Standards/Products/Services for Information/Communication Technologies