RE: Status of SKOS resources (stable, testing etc)

Here is the logic as described in ISO 19135:

8.8.4 status
The derived attribute status shall be represented as an instance of RE_ItemStatus
(8.20) that identifies the registration status of the RE_RegisterItem. The
value is derived through the Addition and Amendment
associations as specified by the constraint:

{if
exists -> (self.amendmentInformation.amendmentType = #retirement
and self.amendmentInformation.disposition = #accepted
and self.amendmentInformation.status = #final)
then self.status = #retired
else if
exists -> (self.amendmentInformation.amendmentType = #supersession
and self.amendmentInformation.disposition = #accepted
and self.amendmentInformation.status = #final)
then self.status = #superseded
else if
exists -> (self.additionInformation.disposition = #accepted
and self.additionInformation.status = #final)
then self.status = #valid
else self.status = #notValid
endif}


>-- Original Message --
>Date: Tue, 29 Jun 2010 18:54:48 +0200
>From: Christophe Dupriez <christophe.dupriez@destin.be>
>Subject: Status of SKOS resources (stable, testing etc)
>
>
>Hi Simon,
>
>You propose an orthogonal representation of the NSDL RegStatus proposal.
>I was (like you) feeling it would be better up to the moment I saw that

>a workflow would be needed (only precise state changes would be allowed).
>Then the NSDL RegStatus seemed a constrained list of possible 
>combinations of the 3 dimensions you indicate.
>
>Whatever is the representation, we need now a table of permitted status

>changes (being one or three variables) with the question asked at each
step:
>it may then be possible to define this to a workflow engine and have for
>"free" a terminology collaboration system!
>http://java-source.net/open-source/workflow-engines
>Anyone knows what is working in practice in this domain?
>
>A simple attempt to fully modelize a workflow is below:
>  (S are states, Q are questions, X are eXceptions/eXits from normal path):
>
>S1: New-Proposed (notValid or retired or superseded if coming from S9,

>accepted,pending) [set by ANYONE]
>Q1: Please Improve up to the point it makes an acceptable proposal for

>the validation committee!
>        X1:Rejected (retired or superseded/notAccepted/final)
>or continues to:
>S2: New-Under review (notValid or retired or superseded if coming from

>S9, accepted,tentative)[set by THESAURUS MANAGER]
>Q2: Does the validation committee accept this new contribution?
>        X2:Rejected S9 (retired/notAccepted/final)
>or continues to:
>S3: Published (valid, accepted,final)[set by VALIDATION COMMITTEE]
>Q3: Some problems with this? (change, deprecate?)
>
>S4: Change-Proposed (valid,accepted,pending) [set by ANYONE]
>Q4: Please Improve up to the point it makes an acceptable change for the
>
>validation committee!
>        X6: return to S3
>or continues to:
>S5: Change-Under review (valid,accepted,tentative) [set by THESAURUS 
>MANAGER]
>Q5: Does the validation committee accept this change?
>        APPLY COMMITTEE DECISION and then return to S3
>
>S6: Deprecate-Proposed (valid,withdrawn,pending)[set by ANYONE]
>Q6: Please justify up to the point it may accepted by the validation 
>committee!
>        X6: return to S3
>or continues to:
>S7: Deprecate-Under review (valid,withdrawn,tentative) [set by THESAURUS
>
>MANAGER]
>Q7: Does the validation committee accept this deprecation?
>        X7: return to S3
>or continues to:
>S8: Deprecated (retired or superseded, withdrawn,final)[set by 
>VALIDATION COMMITTEE]
>Q8: No more information linked with this?
>       X8: Necessary to reactivate, ANYONE can put back in S1 ?
>or continues to:
>S9: Rejected (retired or superseded/notAccepted/final) [set by THESAURUS
>
>MANAGER, may be automated]
>Q9: Do we still feel rejecting this?
>       X9: Necessary to reactivate, ANYONE can put back in S1 ?
>
>My colleagues may help me validate this and make a nice graph, it would

>really help!
>
>Have a nice evening!
>
>Christophe
>
>
>Le 29/06/2010 17:31, Simon Cox a écrit :
>> Also possibly of interest are the values in several enumeration 
>> classes in ISO 19135 (Procedures for registration):
>> RE_ItemStatus::
>> notValid         (i.e. submitted but not yet processed)
>> valid
>> superseded     (i.e. no longer valid but replaced by another item in

>> the register)
>> retired             (i.e. no longer valid but not replaced).
>> RE_Disposition::
>> withdrawn
>> accepted
>> notAccepted
>> RE_DecisionStatus::
>> pending
>> tentative
>> final
>> As you can see, this model elaborates the status values on several axes.
>>
>> --------------------------------------------------------
>> *Simon Cox
>> *
>> European Commission, Joint Research Centre
>> Institute for Environment and Sustainability
>> Spatial Data Infrastructures Unit, TP 262
>> Via E. Fermi, 2749, I-21027 Ispra (VA), Italy
>> Tel: +39 0332 78 3652
>> Fax: +39 0332 78 6325
>> mailto:simon.cox@jrc.ec.europa.eu
>> http://ies.jrc.ec.europa.eu/simon-cox
>>
>> SDI Unit: http://sdi.jrc.ec.europa.eu/
>> IES Institute: http://ies.jrc.ec.europa.eu/
>> JRC: http://www.jrc.ec.europa.eu/
>>
>> --------------------------------------------------------
>>
>> Any opinions expressed are personal unless otherwise indicated.
>>
>>
>>     ------------------------------------------------------------------------
>>     *From:* public-esw-thes-request@w3.org
>>     [mailto:public-esw-thes-request@w3.org] *On Behalf Of *Sue Ellen
>>     Wright
>>     *Sent:* Thursday, 24 June 2010 18:13
>>     *To:* Matthias Löbe
>>     *Cc:* Bernard Vatant; Alistair Miles; Dan Brickley; Marc Wick;
>>     Dublin Core; SKOS; Leigh Dodds; Libby Miller; Lise Rozat
>>     *Subject:* Re: Status of resources (stable, testing etc)
>>
>>     Dear Colleagues,
>>     I am sending an HTML output from the TC 37 ISOcat Metadata
>>     Registry (Data Category Registry) That shows our entry for
>>     //administrative status//, which in many local termbases would
>>     probably appear simply as //term status/. /We have issues within
>>     the collection with distinguishing between different status
>>     values, which is why the standardized data category looks a little
>>     too complicated. The values are indeed the ones that Matthias has
>>     identified in 10241 and they are widely used throughout TC 37
>>     standards and within the terminology management community. (Bear
>>     in mind we are talking discourse/text-oriented terminology here,
>>     which doesn't always behave the same way that SKOS terminology
>>     does, but we've got lots of cross-over points of reference.) If
>>     you look at this file in a browser and move down to the value
>>     domain that is shown at the end, you can link to any one of the
>>     data category specifications that are referenced there. You'll
>>     find that "deprecated" refers to simply any term that is not
>>     considered acceptable, whether it has always been unacceptable or
>>     it has been changed to that status at some time. You will note
>>     that this is something of a bone of contention, because some
>>     linguists don't like the term and prefer to say "not recommended"
>>     in this slot. Frankly, I don't really care what label people use
>>     as long as they document the mapping to the right data category
>>     definition. If you really want to specify that a term was once
>>     used as accepted or preferred, but it has been rejected and
>>     replaced by another term, you can use "superseded". In practice,
>>     most people simply use "preferred", "admitted", and "deprecated"
>>     (or "not recommended" if they belong to that camp).
>>     BTW, the links are mnemonic representations of non-mnemonic
>>     persistent identifiers that resolve the display you will see
>>     through our RESTful interface. If anybody is interested in
>>     referencing concepts from TC 37, we'd love to show you how this
>>     works. We're also advocates of this kind of permanent linking
>>     mechanism between web resources of all kinds, although not
>>     everybody has the simple solution of using a registered ISO domain
>>     to back up a cool URI. Check out  ISOcat at http://www.isocat.org
>>     <http://www.isocat.org/>.
>>     Bye for now
>>     Sue Ellen Wright, Chair, ISOcat Data Category Registry Board
>>
>>     2010/4/29 Matthias Löbe <matthias.loebe@imise.uni-leipzig.de
>>     <mailto:matthias.loebe@imise.uni-leipzig.de>>
>>
>>         Hello to all,
>>
>>         ISO 10241 "International terminology standards" has a scale of
>>         acceptability ratings comprised of: "preferred", "admitted",
>>         "deprecated", "obsolete" and "superseded".
>>
>>         Well, I always read "deprecated" as outdated, obsolete,
>>         superseded,
>>         archaic, "was once approved, but should not used furthermore".
>>
>>         In contrast, I see cases where someone would like to express
a
>>         status
>>         "disapproved" as "We know it might be intuitive to raise such
a
>>         concept and we've discussed it, but for good reason we
>>         declined it and
>>         won't discuss it again." (e.g. when a designation is not best
>>         practice
>>         in a certain context).
>>
>>         M
>>
>>         --
>>         Matthias Löbe, Inst. for Medical Informatics (IMISE),
>>         University of Leipzig
>>         Härtelstr. 16, D-04107 Leipzig, +49 341 97 16113,
>>         loebe@imise.uni-leipzig..de
>>
>>
>>
>>
>>
>>     -- 
>>     Sue Ellen Wright
>>     Institute for Applied Linguistics
>>     Kent State University
>>     Kent OH 44242 USA
>>     sellenwright@gmail.com <mailto:sellenwright@gmail.com>
>>
>>     Terminology management: There is unfortunately no cure for
>>     terminology; you can only hope to manage it. (Kelly Washbourne)
>>
>

Received on Tuesday, 29 June 2010 17:12:01 UTC