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

RE: candidate and deprecated concepts

From: Carl Mattocks <carlmattocks@checkmi.com>
Date: Mon, 11 Oct 2004 12:09:56 -0400 (EDT)
Message-ID: <4465.216.163.247.1.1097510996.squirrel@webmail.netcarrier.com>
To: "Miles, AJ \(Alistair\)" <A.J.Miles@rl.ac.uk>
Cc: "'carlmattocks@checkmi.com'" <carlmattocks@checkmi.com>, public-esw-thes@w3.org

et Al :

I can happily accept that a 'set of  concepts' is a 'candidate' concept
scheme. That is , the concepts and the relationships that define / refine
the meaning per scheme are part of the evolution process that benefits
from evaluation.

carl

<quote who="Miles, AJ (Alistair)">
>
> Carl wrote:
>> I agree that 'Concepts never die'..
>> However, I am struggling with the statement that a concept is unstable
>> is this for a 'candidate' concept ?
>> is a slang word a 'candidate' concept ? and would it be in a
>> thesaurus ?
>> are you referring to the term 'deprecated' ? :-} .
>
> The idea of a 'candidate' I took from traditional thesaurus practise ...
> so
> when new terms are suggested as part of the evolution process, they first
> become 'candidates' for membership in the thesaurus.  If after evaluation
> they are then accepted as full members, they are no longer candidates.
>
> This is distinct from the notion of 'deprecation', which I mean to
> describe
> a concept that should no longer be used for indexing.
>
> N.B. within SKOS Core I would like to be able to make statements about
> *concepts* as candidates in a scheme.
>
> (If someone were to suggest adding a new term as a non-preferred label of
> an
> existing concept, this would be modelled as a 'proposed change to an
> existing concept', and *not* as the introduction of a 'candidate term'.)
>
> Note also, it is perfectly reasonable to publish a concept or set of
> concepts, *without* any statements about which *scheme(s)* they are a part
> of.  In this sense, it is useful for the publishing authority to be able
> to
> state to what extent the concept is *stable* i.e. to what degree it may be
> expected to change in the future.
>
> Obviously there is a connection between these two notions ('status' and
> 'stability'), because it would not be good practise to accept a concept as
> part of a thesaurus if it was still unstable.  However, I believe the two
> notions are functionally independent.
>
> As a point of interest, I would like to encourage a perspective shift.
> Within a semantic web context I think it makes better sense to think of
> the
> first step being for an authority (or individual) to publish a set of
> concepts.  Concept schemes may then be described a posteriori to include
> all
> or some of these published concepts.  This allows for schemes to be
> described that include concepts from multiple sources.  I.e. a concept has
> an existence and a publication status that is independent of the schemes
> (or
> scheme versions) which it participates in.
>
> Carl wrote:
>> Addressing the question of how to note that a
>> candidate/deprecated in one
>> scheme, but not in another...I agree with the proposal that
>> SKOS allows a
>> 'Thesaurus structure (BT-NT ) to be kept independent from the indexing
>> practices/applications ( USE-UF ) relationship that use the
>> Thesaurus'.
>
> This is in effect what will be achieved if we can encourage explicitly
> concept-oriented subject indexing.
>
> Al.
>
>
>
>> -----Original Message-----
>> From: Carl Mattocks [mailto:carlmattocks@checkmi.com]
>> Sent: 11 October 2004 15:18
>> To: Miles, AJ (Alistair)
>> Cc: 'Bernard Vatant'; Stella Dextre Clarke; public-esw-thes@w3.org
>> Subject: RE: candidate and deprecated concepts
>>
>>
>> et Al:
>>
>>
>>
>> n.b. I am also ok using the XTM subjectindicatorref
>>
>> carl
>>
>> <quote who="Miles, AJ (Alistair)">
>> >
>> >
>> >
>> >> Incidentally, a design question that arises (if there is
>> >> consensus that
>> >> making these kinds of statement is valuable) is how to
>> >> represent the fact
>> >> that a concept might be candidate/deprecated in one
>> scheme, but not in
>> >> another.
>> >>
>> >
>> > Also, I think that describing the *stability* of a concept
>> is disctinct
>> > from
>> > describing the *status of a concept wrt a specific scheme*.
>> >
>> > So I would like to be able to say (in RDF) both that:
>> >
>> > 'concept X is unstable'
>> >
>> > ... and ...
>> >
>> > 'concept X is a candidate in scheme Y'.
>> >> The *requirement for stability* dictates that, once a
>> concept has been
>> > published, it should certainly never be deleted, and it
>> should be altered
>> > as
>> > little as possible, ideally not at all.  If this practise
>> is observed, one
>> > can to a large extent guarantee the appropriateness of
>> indexing values
>> > over
>> > time.
>> >
>> > However, the *requirement for fitness* dictates that a
>> concept scheme must
>> > be allowed to evolve to reflect changing patterns of usage,
>> perspectives
>> > and
>> > systems of thought.
>> >
>> > I would like to be able to offer a recommendation as part
>> of the SKOS Core
>> > guide that balances the tension between these two
>> requirements.  So far,
>> > the
>> > best I can come up with is something like:
>> >
>> >   'whenever there is pressure to significantly alter the
>> meaning of a
>> > concept or set of concepts, preference should be given to
>> defining a new
>> > concept or set of concepts, with new unique identifers, and
>> expressing
>> > mapping relationships between the old ('deprecated')
>> concepts and the new
>> > concepts.'
>> > Here, 'deprecated' means 'do not use this concept'.  An
>> 'isReplacedBy'
>> > statement means 'use this concept instead'.  A deprecated concept is
>> > allowed
>> > to persist, to support the backwards compatibility of older subject
>> > indexes.
>> >>
>> > Incidentally, a design question that arises (if there is
>> consensus that
>> > making these kinds of statement is valuable) is how to
>> represent the fact
>> > that a concept might be candidate/deprecated in one scheme,
>> but not in
>> > another.
>> >
>> > Al.
>> >
>> >
>> >>
>> >> > -----Original Message-----
>> >> > From: public-esw-thes-request@w3.org
>> >> > [mailto:public-esw-thes-request@w3.org]On Behalf Of
>> Bernard Vatant
>> >> > Sent: 11 October 2004 10:06
>> >> > To: Stella Dextre Clarke; public-esw-thes@w3.org
>> >> > Subject: RE: candidate and deprecated concepts
>> >> >
>> >> >
>> >> >
>> >> >
>>
>> >> > 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.
>>
>>
>>
>>
>> <quote who="Miles, AJ (Alistair)">
>> >
>> > Bernard wrote:
>> >> 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 :))
>> >>
>> >
>> > Yes, I think this is absolutely crucial as a recommendation.
>> >
>> > N.B. this is why i tried to write about explicitly concept-oriented
>> > indexing: because if the subject-based index is built to
>> take *concept
>> > identifers* and not terms as indexing values, then
>> reshuffling which term
>> > is
>> > the preferred label for a concept is a minor issue.  It
>> doesn't affect
>> > document metadata, and it can be adequately represented in RDF as a
>> > structured history note attached to a *concept*.  (i.e. I
>> see no need to
>> > talk about 'deprecated terms').
>> >
>> > However, once we do have explicitly concept-oriented
>> subject indexes,
>> > further change issues arise.
>> >
>>
>> > Al.
>> >
>> >
>> >
>> >> -----Original Message-----
>> >> From: public-esw-thes-request@w3.org
>> >> [mailto:public-esw-thes-request@w3.org]On Behalf Of Bernard Vatant
>> >> Sent: 11 October 2004 10:06
>> >> 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.
>> >>
>> >> > 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
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>> --
>> Carl Mattocks
>>
>> co-Chair OASIS (ISO/TS 15000) ebXMLRegistry Semantic Content SC
>> co-Chair OASIS Business Centric Methodology TC
>> CEO CHECKMi
>> v/f (usa) 908 322 8715
>> www.CHECKMi.com
>> Semantically Smart Compendiums
>> (AOL) IM CarlCHECKMi
>>
>
>


-- 
Carl Mattocks

co-Chair OASIS (ISO/TS 15000) ebXMLRegistry Semantic Content SC
co-Chair OASIS Business Centric Methodology TC
CEO CHECKMi
v/f (usa) 908 322 8715
www.CHECKMi.com
Semantically Smart Compendiums
(AOL) IM CarlCHECKMi
Received on Monday, 11 October 2004 16:09:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:45:16 UTC