Just starting to go through these pages but as a practising author looking at this list it reminds me of the dilemma we face daily when trying to decide which of these to use.
I am hoping this project will help me to choose which of these inactivation scenarios to select. I know discussions here have flagged up lots of examples of cases when these have been used inappropriately by authors, and to me that points to the fact that often it is very difficult to decide between them and this has caused the inconsistencies highlighted by this Working Group.
My initial thoughts are: Duplicate Component yes keep this it is a straightforward a = b
Ambiguous/Erroneous/Nonconformance to Ed Policy/Outdated - I think these 4 are often all overlapping as a concept reason for inactivation and sometimes any or all of these reasons could be selected but when you get down to basics they mean 'something needs to be amended here'. I know it is radical but suggest replace them all with one reason something like 'Updated Component' and cut out the inconsistencies at once
Hi Jeremy Rogers when you say in a comment elsewhere that "Reasons for Inactivation - which, incidentally, probably nobody outside authoring centres really care about; they probably really ARE functionally mere jottings in the margins" do you mean that in essence Ambiguous/Erroneous/Nonconformance to Ed Policy/Outdated (often there are overlapping reasons for inactivation) COULD be replaced by 'Updated Component' or similar.
Well, I've never really found a lot of use at run time for the stated reasons for something being inactivated, whereas by contrast the declared historical associations are paramount. Knowing when a thing is inactive is of course very important. But not usually exactly why: you can't infer much from it.
Other implementors, feel free to disagree...
I think historically the supposed value of asking authors to first select a specific flavour of inactivation reason was that this was then used at author time to direct/constrain which flavours of historical association were then to be offered for selection by the same author. It was, essentially, a cognitive stepping stone on the way to the information that really matters. But we know this two-step process does not always offer the right expressivity of historical association, and empirically the quality/utility of the historical association information that has been created over the years suggests it doesn't work so well. It feels like a cart-before-horse problem.
If we were to turn the entire concept inactivation process on its head, and direct authors instead to focus first and foremost on the "what next" historical association aspect of the problem and not the initial "why", then the role of the "reason for inactivation" in restricting your follow-on choices of association becomes redundant. Your choice of "why" would instead be constrained by your prior declaration of "what next", rather than the other way around. If, in fact, it needs constraining at all since it does not appear to serve any useful functional purpose at runtime. (Other implementors, feel free to disagree...)
Cathy Richardson I don't believe I have seen topic discussed here by the EAG Inactivation Group but presume they will be taking our review comments forward for discussion. I raised it based on my practical experience of finding that inactivation reasons usually overlap and it is often unclear as to which to select, and from reading the examples raised by the group of where we have been inconsistent, and also trying to understand the nuances (and I reviewed the Authoring Level 1 Inactivation Course so I know how difficult this is to teach to new authors in order to create some consistency).
Jeremy says above that as an implementer he does not find the actual Inactivation reason that useful and it is only of use as a way to point to the historical association value. But if that is so then the confusing and overlapping reasons that we select as authors (Ambiguous/Erroneous/Nonconformance to Ed Policy/Outdated) are acting to hinder and obscure the choice of the correct historical association. To me this is the heart of the problem.
That is why I can see sense in Jeremy's statement to direct authors instead to focus on the historical association aspect of the problem and not the initial "why" so perhaps the idea is reasonable of having 2 reasons "Duplicate Component" assigned from initially selecting SAME_AS (i.e. turning the process on its head) and also an "Updated Component" reason assigned by the selection of either POSSIBLY_EQUIVALENT_TO and REPLACED_BY.
This is really good - and if you remember back to our original discussion at the internal editors session exactly the reason why I began by concentrating on the association values. The Inactivation Group have discussed this approach during one of our sessions and would like to pursue it further.
It would be really helpful if we could continue to develop this approach and consider whether the current set of association values are sufficient and specific enough or whether others should be added.
Finally, while I agree that the inactivation reason may be of secondary importance from an implementers perspective I still think it has an important role to play in the "cognitive process" of addressing inactivation.
I get a bit concerned about "starting at the end" WRT to selecting the historical relationship without understanding why a concept needs to be inactivated. I do agree that the primary reason for selecting an inactivation reason "guides" the author to the correct historical relationship(s). But I also think it is important to know why a concept needs to be inactivated. I also agree that many of our inactivation reasons overlap and make it difficult to choose the correct one. I am hoping that this group would be able to produce a more robust set of inactivation reasons, with clear guidance on when each should be used ( I haven't read all of the documentation yet). As I noted on the page related to POSSIBLY-EQUIVALENT-TO there are scenarios where a concept is in fact ambiguous, but there is no compelling reason to add two (or more) historical relationships. The notion of "vagueness", where it is difficult to extract any unique meaning from an FSN, need to be addressed. There are also instances of multiple combined disorders (i.e. X AND Y AND Z) which are not ambiguous, but also not able to be sufficiently defined due to limitations of the concept model and would be better represented by multiple concepts. Broad-based inactivation reasons such as "Non-conformance to editorial policy" do not really fit in these cases.
9 Comments
Nicola Ingram
Just starting to go through these pages but as a practising author looking at this list it reminds me of the dilemma we face daily when trying to decide which of these to use.
I am hoping this project will help me to choose which of these inactivation scenarios to select. I know discussions here have flagged up lots of examples of cases when these have been used inappropriately by authors, and to me that points to the fact that often it is very difficult to decide between them and this has caused the inconsistencies highlighted by this Working Group.
My initial thoughts are: Duplicate Component yes keep this it is a straightforward a = b
Ambiguous/Erroneous/Nonconformance to Ed Policy/Outdated - I think these 4 are often all overlapping as a concept reason for inactivation and sometimes any or all of these reasons could be selected but when you get down to basics they mean 'something needs to be amended here'. I know it is radical but suggest replace them all with one reason something like 'Updated Component' and cut out the inconsistencies at once
Nicola Ingram
Hi Jeremy Rogers when you say in a comment elsewhere that " Reasons for Inactivation - which, incidentally, probably nobody outside authoring centres really care about; they probably really ARE functionally mere jottings in the margins" do you mean that in essence Ambiguous/Erroneous/Nonconformance to Ed Policy/Outdated (often there are overlapping reasons for inactivation) COULD be replaced by 'Updated Component' or similar.
Jeremy Rogers
Well, I've never really found a lot of use at run time for the stated reasons for something being inactivated, whereas by contrast the declared historical associations are paramount. Knowing when a thing is inactive is of course very important. But not usually exactly why: you can't infer much from it.
Other implementors, feel free to disagree...
I think historically the supposed value of asking authors to first select a specific flavour of inactivation reason was that this was then used at author time to direct/constrain which flavours of historical association were then to be offered for selection by the same author. It was, essentially, a cognitive stepping stone on the way to the information that really matters. But we know this two-step process does not always offer the right expressivity of historical association, and empirically the quality/utility of the historical association information that has been created over the years suggests it doesn't work so well. It feels like a cart-before-horse problem.
If we were to turn the entire concept inactivation process on its head, and direct authors instead to focus first and foremost on the "what next" historical association aspect of the problem and not the initial "why", then the role of the "reason for inactivation" in restricting your follow-on choices of association becomes redundant. Your choice of "why" would instead be constrained by your prior declaration of "what next", rather than the other way around. If, in fact, it needs constraining at all since it does not appear to serve any useful functional purpose at runtime. (Other implementors, feel free to disagree...)
Nicola Ingram
I agree
Cathy Richardson
Interesting point here Nicola Ingram and Jeremy Rogers. What input has been sought from this group of users?
Nicola Ingram
Cathy Richardson I don't believe I have seen topic discussed here by the EAG Inactivation Group but presume they will be taking our review comments forward for discussion. I raised it based on my practical experience of finding that inactivation reasons usually overlap and it is often unclear as to which to select, and from reading the examples raised by the group of where we have been inconsistent, and also trying to understand the nuances (and I reviewed the Authoring Level 1 Inactivation Course so I know how difficult this is to teach to new authors in order to create some consistency).
Jeremy says above that as an implementer he does not find the actual Inactivation reason that useful and it is only of use as a way to point to the historical association value. But if that is so then the confusing and overlapping reasons that we select as authors (Ambiguous/Erroneous/Nonconformance to Ed Policy/Outdated) are acting to hinder and obscure the choice of the correct historical association. To me this is the heart of the problem.
That is why I can see sense in Jeremy's statement to direct authors instead to focus on the historical association aspect of the problem and not the initial "why" so perhaps the idea is reasonable of having 2 reasons "Duplicate Component" assigned from initially selecting SAME_AS (i.e. turning the process on its head) and also an "Updated Component" reason assigned by the selection of either POSSIBLY_EQUIVALENT_TO and REPLACED_BY.
Paul Amos
Hi All,
This is really good - and if you remember back to our original discussion at the internal editors session exactly the reason why I began by concentrating on the association values. The Inactivation Group have discussed this approach during one of our sessions and would like to pursue it further.
It would be really helpful if we could continue to develop this approach and consider whether the current set of association values are sufficient and specific enough or whether others should be added.
Finally, while I agree that the inactivation reason may be of secondary importance from an implementers perspective I still think it has an important role to play in the "cognitive process" of addressing inactivation.
Best wishes
Paul
Cathy Richardson
If inactivation reasons were to go I'd be wary of using 'replaced by' for concepts that are ambiguous. I'd prefer 'possibly equivalent to'.
Jim Case
I get a bit concerned about "starting at the end" WRT to selecting the historical relationship without understanding why a concept needs to be inactivated. I do agree that the primary reason for selecting an inactivation reason "guides" the author to the correct historical relationship(s). But I also think it is important to know why a concept needs to be inactivated. I also agree that many of our inactivation reasons overlap and make it difficult to choose the correct one. I am hoping that this group would be able to produce a more robust set of inactivation reasons, with clear guidance on when each should be used ( I haven't read all of the documentation yet). As I noted on the page related to POSSIBLY-EQUIVALENT-TO there are scenarios where a concept is in fact ambiguous, but there is no compelling reason to add two (or more) historical relationships. The notion of "vagueness", where it is difficult to extract any unique meaning from an FSN, need to be addressed. There are also instances of multiple combined disorders (i.e. X AND Y AND Z) which are not ambiguous, but also not able to be sufficiently defined due to limitations of the concept model and would be better represented by multiple concepts. Broad-based inactivation reasons such as "Non-conformance to editorial policy" do not really fit in these cases.