[Zthes] More on Extensions to ZThes Elements

Mike Taylor mike at indexdata.com
Fri Jun 18 12:50:56 CEST 2004

> Date: Thu, 17 Jun 2004 13:05:44 -0600
> From: "Dave Clarke" <dclarke at synaptica.com>
>     Synaptica allows n user-defined notes fields to be specified for
>     each vocabulary.
> <NoteLabel>
>     Name or label of notes field.
> <NoteValue>
>     Value of notes field for a specific term.

So this is really a set of label=value pairs?  Like this:

	  Some random prose, such as is already allowed by the profile
	    <noteValue>Taken from Webster's, 2nd ed.</noteValue>
	    <noteValue>Considered silly</noteValue>


I would be a bit concerned about the mixed content-model in termNote
if we allowed this -- it's hard to write constraints for.  How would
it be if instead we extended the top-level record so that as well as
the existing <termNote> (which would stay unchanged) we also allowed
zero or more <termNotePair>s?  Your application would use the latter
and presumably not bother with the former.

> <relationWeight>
>     Synaptica allows relationships between terms to be
>     weighted. This is rarely used within a thesaurus, but is often
>     used when mapping multiple thesauri together.

Ooo!  Shiny!  :-)

> IN ADDITION to those listed above we also anticipate the need to
> break the termName element down into n user-defined sub-fields to be
> specified for each particular vocabulary. Synaptica already supports
> this for named entity and classification scheme vocabularies where,
> for example, one might need sub elements for First Name, Middle
> Names and Last Name or Classification Code and Classification
> Description. We would propose a similar solution to that shown above
> for the <termNotes> element:
>     Synaptica allows n user-defined term name sub-fields to be
>     specified for each particular vocabulary. 
> <NameLabel>
>     Name or label of term name sub-field.
> <NameValue>
>     Value of term name sub-field for a specific term.

Hmm.  As with <termNote>, the mixed content would worry me; I would
probably suggest that these new pairs should go alongside <termName>
rather than within it.  We would then lose the invariant that the
{termName, termQualifier} combination is unique across the database,
but I don't think anyone's using that property anyway.  We would still
need to insist on <termId> being unique, though.

> If the above model were adopted we would also suggest that
> consideration be given to supercede the <termQualifier> element with
> the new sub-elements since a term qualifier could easily be declared
> as a type of <NameLabel>.

I agree.  However, this would be (I think) the only
backward-incompatible change you've proposed; so before committing to
it, I would like to hear from everyone else concerning whether they've
been using <termQualifier>.

 _/|_	 _______________________________________________________________
/o ) \/  Mike Taylor  <mike at indexdata.com>  http://www.miketaylor.org.uk
)_v__/\  "Normally Sir, yes.  Today, the van broke down" --  _Cheese
	 Shop_ sketch, Monty Python's Flying Circus.

Listen to free demos of soundtrack music for film, TV and radio

More information about the Zthes mailing list