Re: Status of SKOS resources (stable, testing etc) : supersededBy ???

Dear Simon,

Thank you very much for the information!
It shows that the ISO 19135 describes how amendments are coded and 
interpreted to provide current (and previous) status information.

I do not have the ISO 19135 at hand (100 euros requested for a copy).
Wikipedia provides a link to the TOC:
http://de.wikipedia.org/wiki/ISO_19135

If I stay with the NSDL RegStatus (which does not have "superseded"),
Supersession could be represented by a "supersededBy" relation from the 
superseded (retired) concept to the replacing one.
The state machine remains very simple (retired or superseded is decided 
based upon the presence of "supersededBy".

"supersededBy" is therefore a sub-topic for this discussion. How could 
it be represented?

In my local SKOS implementation, I have an "alias" field to implement a 
"superseding" information (not a relation):
only the identifier of the superseded concept is kept as an "alias" to 
ensure that old data is indexed to the new Concept identifier.

What would be an elegant way to represent supersession (superseded / 
superseding) as a relation between two concepts
OR as a simple trace of a previous identifier redirected to a new one 
(like with HTTP status 301 where the old page is not accessible)?

My two cents:
1) renaming my "alias" field to "superseding" which can be a literal 
(old Identifier of deleted concept) or a relation (URL of 
deprecated/retired concept).
     This shows that a superseded concept can be deprecated (retirement 
cannot be complete because old data must be reindexed)
      or retired (no more data uses the superseded concept but one wants 
to keep trace of it). This requires an independent "supersededBy" field.
2) adding an optional "supersededBy" relation containing the URL of the 
new Concept
     (or ConceptS if the replacements request a human decision, indexed 
record by indexed record)

Have a nice evening,

Christophe

Le 30/06/2010 14:33, Simon Cox a écrit :
> Now I've seen how the appalling webmail client provided by my employer
> garbled that I think it is worth trying again:
>
> 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}
>
> (I guess this is OCL.)
>
> --------------------------------------------------------
> 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.
>
> -----Original Message-----
> From: public-esw-thes-request@w3.org [mailto:public-esw-thes-request@w3.org]
> On Behalf Of Simon Cox
> Sent: Tuesday, 29 June 2010 19:11
> To: Christophe Dupriez
> Cc: 'Sue Ellen Wright'; 'Matthias Löbe'; 'Bernard Vatant'; 'Alistair Miles';
> 'Dan Brickley'; 'Marc Wick'; 'Dublin Core'; 'SKOS'; 'Leigh Dodds'; 'Libby
> Miller'; 'Lise Rozat'; Dominique Vanpée; Wim Daeleman
> Subject: 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 Monday, 5 July 2010 16:37:44 UTC