(unknown charset) Re: [VM] Configuration management for RDFS/OWL ontologies

I find the name confusing but I really like the requirements
you lay out.  Maybe the document should start with those.

With "configuration management", I feel confused as to whether
something is being configured (i.e., according to a process
that needs to managed) or if it is "the configuration" itself
-- i.e., perhaps, a structure of properties and classes --
that is being managed.


On Thu, Jul 07, 2005 at 01:36:13PM +0100, Alistair Miles wrote:
> Perhaps a slightly confusing name, but in a project management (e.g. prince2) context 'configuration management' means a system for controlling change to ensure quality, and that's what we need for RDF vocabs.  I.e. we need to know how to support *commercial strength* RDF vocab and ontology development.
> If you've got 'The Little Prince2' look at section 6.1.1 'Planning Quality' ... very useful, tho I better not reproduce it here for fear of copyright infringement.  It highlights 5 processes:  
> Planning: this is what we did when we discussed the policy statements section of the SKOS Core spec - we decided what level of configuration management is required, and we wrote a process for achieving it.
> Identification: this means identifying all the components of a product.  In the case of SKOS Core this is all the properties and classes, in the case of a generic RDF vocab it could be modules as well.
> Control: this means 'freezing' products and making changes only within a formal (or at least clearly defined) procedure, involving e.g. access rights, version tracking.  For SKOS Core this is editorial responsibility, historical snapshots, and the review process.
> Status accounting: this means keeping a record of current and historical data for a product, especially relating to the status of the product.  For SKOS Core this is per-term stability levels. 
> Verification: verifying that actual status matches recorded/authorised status.  We could do that e.g. by checking if changes have occurred to a class or prop between versions that are not allowed by the term's stability level.
> An analogy is e.g. car or aerospace engineering.  With good configuration management you can track a problem back to the specific batch of faulty nuts or bolts.  With poor configuration management you have no idea what went wrong or how to fix it. 
> Cheers,
> Al.
> [1] http://en.wikipedia.org/wiki/Configuration_management

Dr. Thomas Baker                      baker@sub.uni-goettingen.de
SUB - Goettingen State                            +49-551-39-3883
and University Library                           +49-30-8109-9027
Papendiek 14, 37073 Göttingen

Received on Thursday, 7 July 2005 12:50:13 UTC