-
Notifications
You must be signed in to change notification settings - Fork 4
Description
Simon Cox: xsd:enumeration is a very blunt instrument for controlled vocabs, particularly when they are mutable.
‘enumeration’ implies that the set is known to be complete.
Of the set of vocabularies I see in the includes, probably only accessType could be even imagined to be fixed.
I realise that xsd:enumeration helps you spin up a UI quickly I know, but it is not at all scalable.
It also means that whenever you want to add an entry to a vocabulary you will have to make a new version of the XSD.
That is really storing up trouble.
Revision of these vocabularies will generally on a faster timescale than the data structure, so it is helpful to decouple them.
The usual way to do that is to maintain the vocabularies at least in a separate XML namespace, and probably not in XML at all.
I’m also highly surprised to see all new vocabularies. I spoke about this in my SciDataCon keynote [1] – wasn’t anyone listening?
There are many existing well-maintained vocabs that are relevant (too many in fact – but that’s no reason to proliferate further!), like
-
http://www.iana.org/assignments/link-relations/link-relations.xhtml or http://vocabulary.odm2.org/relationshiptype/ for relationType -
other ODM2 vocabularies http://vocabulary.odm2.org/
o http://vocabulary.odm2.org/medium/ for materialType
o http://vocabulary.odm2.org/samplingfeaturegeotype/ for geometryType
-
http://registry.it.csiro.au/def/isotc211/CI_RoleCode for contributor-types
Many of these are published with a URI per item, so you can leave them where they are, and refer to the value by URI.
As well as solving the maintenance issue, it makes your data more likely to be interoperable with other data on the web.
Building a closed system with all tagging just using text looks like quite a few steps backwards to me …