W3C home > Mailing lists > Public > public-esw-thes@w3.org > October 2004

RE: candidate and deprecated concepts

From: Miles, AJ (Alistair) <A.J.Miles@rl.ac.uk>
Date: Mon, 11 Oct 2004 13:39:42 +0100
Message-ID: <350DC7048372D31197F200902773DF4C05E50C95@exchange11.rl.ac.uk>
To: 'Stella Dextre Clarke' <sdclarke@lukehouse.demon.co.uk>, 'Bernard Vatant' <bernard.vatant@mondeca.com>, public-esw-thes@w3.org

Hi all,

Just to qualify this discussion - I'm trying to write a section on scheme
versioning and change management for the new SKOS Core guide.  What I've got
so far is on the SkosDev wiki at:

http://esw.w3.org/topic/SkosCoreGuideToc/SectionVersioning

This section is trying to describe how you can capture and represent as RDF
information about versions of and changes to a concept scheme.  

Anyway, thought I'd put this out there so it can be talked about.

Al.

---
Alistair Miles
Research Associate
CCLRC - Rutherford Appleton Laboratory
Building R1 Room 1.60
Fermi Avenue
Chilton
Didcot
Oxfordshire OX11 0QX
United Kingdom
Email:        a.j.miles@rl.ac.uk
Tel: +44 (0)1235 445440



> -----Original Message-----
> From: public-esw-thes-request@w3.org
> [mailto:public-esw-thes-request@w3.org]On Behalf Of Stella 
> Dextre Clarke
> Sent: 11 October 2004 10:46
> To: 'Bernard Vatant'; public-esw-thes@w3.org
> Subject: RE: candidate and deprecated concepts
> 
> 
> 
> Bernard,
> Interesting discussion, and I wish I had time to follow up on the idea
> of an indexing profile separate from a thesaurus. Could be very useful
> in some interoperability scenarios. 
> 
> But for now I'll just comment that I had thought "deprecated term" was
> an Americanism, synonymous with "non-preferred term", creeping across
> the Atlantic. Seems you in Mondeca use it as an NT of "non-preferred
> term". I wonder how everyone else uses it...?
> 
> By the way, you might be interested to know that BSI has just issued
> DPCs (Drafts for Public Comment) of the first two parts of BS8723 -
> something  which one day we hope will supersede BS5723 (=ISO 2788) and
> BS6723 (=ISO5964). The documents have numbers 04/30086620 DC and
> 04/30094113 DC respectively, and are said to be available from
> orders@bsi-global.com, probably only on payment. BSI has so far been
> unable to give any more info about how to get them, certainly 
> not about
> how to download them from anywhere. But comments from people like you
> could help the standards evolve to take account of new practices.
> 
> Cheers
> Stella
> 
> *****************************************************
> Stella Dextre Clarke
> Information Consultant
> Luke House, West Hendred, Wantage, Oxon, OX12 8RR, UK
> Tel: 01235-833-298
> Fax: 01235-863-298
> SDClarke@LukeHouse.demon.co.uk
> *****************************************************
> 
> 
> 
> -----Original Message-----
> From: Bernard Vatant [mailto:bernard.vatant@mondeca.com] 
> Sent: 11 October 2004 10:04
> To: Stella Dextre Clarke; public-esw-thes@w3.org
> Subject: RE: candidate and deprecated concepts
> 
> 
> 
> Stella
> 
> > The difference between a deprecated concept and a 
> deprecated term may 
> > not be as clear as you might wish.
> 
> Sure, no more than the difference between a term or a concept,
> deprecated or not :)
> 
> > (And even the word "deprecated" is a
> > bit strange to me in the context of thesauri. We usually just say
> > non-preferred.)
> 
> Indeed? We currently in Mondeca work for a major actor in legal
> publication (Wolters Kluwer Belgium), making a very intensive use of
> Thesauri, including e.g. their use for automatic generation of
> publication index. And one of the strong requirements of the folks in
> charge of Thesaurus management was indeed a proper handling 
> of what they
> call "deprecated terms". A deprecated term is a term that used to be
> preferred, and used as such, and at some point of time in the 
> history of
> the vocabulary was replaced by another preferred term. After
> "deprecation" (so to speak) the once-preferred, and now 
> deprecated term,
> is kept as a synonym of the preferred term which replaces it. Whatever
> relationships (BT-NT, USE, ...) of the deprecated term are 
> re-located to
> the replacing term, and indexation of documents is redirected.
> 
> So of course a deprecated term is non-preferred, but it used 
> to be, and
> the system keeps track of that if necessary.
> 
> > It is unusual to drop a concept altogether.
> 
> Of course the concept does not really change because the term is
> deprecated, since it's replaced, it's simply the preferred term for it
> that changes. Concepts never die :)
> 
> > Normally one provides a lead-in entry pointing to the 
> broader concept 
> > that covers the scope of the preferred term that is now to be 
> > "deprecated". It is conceivable that if it was decided that a large 
> > subject area with perhaps hundreds of concepts was now 
> out-of-scope, 
> > then all the corresponding terms might be dropped without trace ( 
> > although this is not usually recommended). The thesaurus 
> might well be
> 
> > renamed or rebranded to mark the transition.
> 
> This is another story ...
> 
> > Much more likely would be to decide that that subject area 
> should be 
> > indexed at a much shallower level of specificity.
> 
> I think Thesaurus structure can (should) be kept independent from the
> indexing practices/applications that use the Thesaurus. See at the end
> the general remak about declarative vs procedural properties. Several
> different indexing applications can use the same Thesaurus at 
> different
> levels of granularity, use or not use specific branches etc 
> ... This is
> the notion of index profile (also a requirement of the above quoted
> customer). The index profile can be managed independently of the
> structure of the thesaurus itself. You can say e.g. in the 
> profile that
> you only use the three first levels of the Thesaurus hierarchy, so
> whatever is indexed at a finer level of granularity will be re-indexed
> by the relevant parent.
> 
> > So, for example, in a
> > thesaurus for agricultural products, it might be decided 
> that tropical
> 
> > products should no longer be covered in detail. Where 
> previously you 
> > had Bananas, Pineapples, Brazil nuts etc as preferred terms 
> ( with a 
> > hierarchy of BTs such as Tropical fruits all the way up to Tropical 
> > products), you might leave just one term "Tropical 
> products" to cover 
> > all of these. In the thesaurus you would organise entries such as 
> > "Bananas USE Tropical products" - perhaps hundreds of such entries. 
> > Now where is the "deprecated concept"? All we have is one 
> very broad 
> > concept taking in tropical products at all levels of 
> detail, and lots 
> > of non-preferred terms.
> 
> This is quite different from deprecation, it's changing the 
> granularity
> of the Thesaurus. And in such a case, you could just change 
> the indexing
> profile, saying now that "Tropical Products" is a "leaf term" for the
> indexing profile (meaning that everything below should be indexed on
> that term).
> 
> > So the idea of a "deprecated concept" just feels a bit alien.
> 
> Yes, there again, concepts never die. This is an important rule I've
> found out in topic map management : never delete a topic. Change its
> status, attributes, names, relationships, date of validity, but never
> delete. Once you have spoken about something at some point, this thing
> exists forever, at least as a subject of conversation :))
> 
> > I don't warm, either, to the idea of a concept getting 
> "replaced" by 
> > another one, unless they are so close that you would treat 
> the two as 
> > quasi-synonymous. You are hardly going to replace Bananas 
> with Washing
> 
> > machines?
> 
> There again, only terms are replaced, not concepts.
> 
> Bottom line : We need here to make distinct the *declarative* 
> properties
> of concepts, valid whatever the context of application and the
> *procedural* properties, applicable only in specific contexts of use.
> For example seems to me that the BT-NT relationship between "Tropical
> Fruits" and "Bananas" should be declarative, and kept 
> existing whatever
> the context, whereas the USE-UF relationship stated in order 
> to use the
> Thesaurus at a broader level of granularity, is procedural: you know
> pretty well that "Tropical Fruits" and "Bananas" are distinct 
> concepts,
> but in a certain context of application this distinction is 
> useless for
> whatever reason. It's different from, say, you had an ancient
> astronomical thesaurus where "Evening Star" and "Morning Star" were
> thought as distinct concepts, and you decide/discover at some 
> point that
> in fact they both have to be replaced by "Planet Venus". In 
> this latter
> case, there is actually a (declarative) change in the 
> conceptual scheme.
> It might be that the USE-UF relationship in Thesaurus is 
> sometimes used
> in a declarative sense, and sometimes in a procedural sense, 
> leading to
> some ambiguities. The above quoted notion of "index profile" allows to
> capture the procedural properties for various contexts, while not
> changing the declarative properties in the (common) Thesaurus.
> 
> Regards
> 
> Bernard
> 
> Bernard Vatant
> Senior Consultant
> Knowledge Engineering
> Mondeca - www.mondeca.com
> bernard.vatant@mondeca.com
> 
> 
> 
> 
Received on Monday, 11 October 2004 12:40:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 13:32:04 UTC