OASIS XML Localisation Interchange File Format (XLIFF) TC

Hi David, all, To follow-up on issue 130. This type of annotation didn't exist in the core of the cs02. It has been added between cs02 and cs03 I'm not sure why as it seems it's not mentioned in either the wiki tracking or the list of changes in the document (I may have missed something though) The Matches module should define what is used, not the core. > Translation Candidates annotation is a core device for pointing to > translation candidates analogical to the term annotation. > It can be used by the module but really is independent of it, same > as the term annotation is independent of the glossary module. The case of the term annotation is completely different: it's used to denote terms and the reference to additional information is only optional. > This is the case especially after matches got their own ref for > pointing back to core. Actually having matches holding the ref shows an annotation is not even needed now as you can point directly to a segment (something I don't like as it may result loosing information when you re-segment the content). By the way: the Matches section doesn't explicitly say if you can or cannot do that, but no constraint forbid it and the wording technically allow it. (and obviously that was one of the main point of Dave). In general I don't think it's good to define module-specific metadata in the core. So far this annotation is the only one doing that. So I still strongly suggest to remove that section 4.7.3.1.3 and define the mtc:match as a type for <mrk> in the Matches module, where IMO it belongs. Side note: The example 4.3.1.22 has a match example, but doesn't use the latest Matches mechanism (ref from the match). Cheers, -yves

I don't think re-segmentation and annotation would be a problem; data can always be duplicated the worst case. However, I agree with your opinion in principle regarding annotation. From:         Yves Savourel <ysavourel@enlaso.com> To:         <xliff@lists.oasis-open.org> Date:         12/26/2013 12:05 PM Subject:         [xliff] 130 candidate annotation in Dec-17 Draft Sent by:         <xliff@lists.oasis-open.org> Hi David, all, To follow-up on issue 130. This type of annotation didn't exist in the core of the cs02. It has been added between cs02 and cs03 I'm not sure why as it seems it's not mentioned in either the wiki tracking or the list of changes in the document (I may have missed something though) The Matches module should define what is used, not the core. > Translation Candidates annotation is a core device for pointing to > translation candidates analogical to the term annotation. > It can be used by the module but really is independent of it, same > as the term annotation is independent of the glossary module. The case of the term annotation is completely different: it's used to denote terms and the reference to additional information is only optional. > This is the case especially after matches got their own ref for > pointing back to core. Actually having matches holding the ref shows an annotation is not even needed now as you can point directly to a segment (something I don't like as it may result loosing information when you re-segment the content). By the way: the Matches section doesn't explicitly say if you can or cannot do that, but no constraint forbid it and the wording technically allow it. (and obviously that was one of the main point of Dave). In general I don't think it's good to define module-specific metadata in the core. So far this annotation is the only one doing that. So I still strongly suggest to remove that section 4.7.3.1.3 and define the mtc:match as a type for <mrk> in the Matches module, where IMO it belongs. Side note: The example 4.3.1.22 has a match example, but doesn't use the latest Matches mechanism (ref from the match). Cheers, -yves --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Yves, let me react and explain You are right that this annotation has been first introduced in reaction to prohibiting metadata on segment, i.e. between csprd01 and csprd02 However, the situation is anyways strictly analogical to the term annotation. The term annotation is to be used by the glossary module to point back to the content, however the term annotation can work without the glossary module for those who chose not use the glossary module. So the translation candidate annotation can work as a core device for people who are not using the translation candidates module, and want  instead to point to leverage resources external to the XLIFF document. When implementing the translation candiadate annotation I considered the option to define it in the module. However it seems bad design to me for a couple of reasons: - The analogy with term and glossary as explained above - Module cannot define a core value, if the value was to be defined in the module it would need to be an mtc: prefixed value. This value would not be accessible for people who want to use an external leverage resource, which seems legitimate to me So IMHO the translation candidate annotation is a valid core device that is independent of storage of candidates within the mtc module. I think that the core annotation together with the mtc module address the feature request documented in the wiki. Thanks and regards dF   Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Thu, Dec 26, 2013 at 5:01 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi David, all, To follow-up on issue 130. This type of annotation didn't exist in the core of the cs02. It has been added between cs02 and cs03 I'm not sure why as it seems it's not mentioned in either the wiki tracking or the list of changes in the document (I may have missed something though) The Matches module should define what is used, not the core. > Translation Candidates annotation is a core device for pointing to > translation candidates analogical to the term annotation. > It can be used by the module but really is independent of it, same > as the term annotation is independent of the glossary module. The case of the term annotation is completely different: it's used to denote terms and the reference to additional information is only optional. > This is the case especially after matches got their own ref for > pointing back to core. Actually having matches holding the ref shows an annotation is not even needed now as you can point directly to a segment (something I don't like as it may result loosing information when you re-segment the content). By the way: the Matches section doesn't explicitly say if you can or cannot do that, but no constraint forbid it and the wording technically allow it. (and obviously that was one of the main point of Dave). In general I don't think it's good to define module-specific metadata in the core. So far this annotation is the only one doing that. So I still strongly suggest to remove that section 4.7.3.1.3 and define the mtc:match as a type for <mrk> in the Matches module, where IMO it belongs. Side note: The example 4.3.1.22 has a match example, but doesn't use the latest Matches mechanism (ref from the match). Cheers, -yves --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Hi David, all, > However, the situation is anyways strictly > analogical to the term annotation. > The term annotation is to be used by the glossary module > to point back to the content, however the term annotation can > work without the glossary module for those who chose > not use the glossary module. I think it's different. Maybe it's simpler to look at it from the core viewpoint: My test question for determining if an annotation type should be part of the core or not is: "Can this annotation with only its required attributes be use just with the core elements?" The answer is yes for the term annotation, the translate annotation and the comment annotation. But it is no for the translation candidate annotation. <mrk id='1' type='term'>text</mrk> by itself identifies 'text' as a term. <mrk id='1' type='match'>text</mrk> by itself is useless. > So the translation candidate annotation can work as a core > device for people who are not using the translation candidates > module, and want instead to point to leverage resources > external to the XLIFF document. I would say those people should definitely use their own annotation type, so processors would know what kind of data the ref attribute would point to, otherwise it'll useless. Since you are not defining it. And yes, we do have that ref for the term annotation as well. And the target of the ref is as vague as for the translation candidate annotation. But it has two aspects that are different: - just displaying the information in the case of the term annotation is most likely useful, while in the case of applying a match you would really need to know more that just the pointed content (i.e. you would need to know how to get the score info, the source/target text, etc. from that content). - The term annotation was in 1.2, not the translation candidate annotation. I don't think we ever discussed this feature, if anyone request it, if anyone actually implemented it, etc. As for ref in term, I would be fine with dropping the ref feature from the term annotation for 2.0. If we think it should be better defined and just displaying the information is not be good enough for 2.0. But that is a separate issue from the translation candidate annotation. And, the important point is that even without ref the term annotation would still be useful in core. > When implementing the translation candidate annotation > I considered the option to define it in the module. > However it seems bad design to me for a couple of reasons: > > - The analogy with term and glossary as explained above IMO the analogy is not true all the way and doesn't stand the test question. > - Module cannot define a core value, if the value was to > be defined in the module it would need to be an mtc: prefixed > value. This value would not be accessible for people who > want to use an external leverage resource, which > seems legitimate to me As I said above, users who want to access some useful external reference mechanism should define it and use their own annotation type. Otherwise if two different mechanisms are defined, how would you make a distinction and know which process to use? Cheers, -yves

Hi David, all, The glossary ref attribute is defined as: "points to a span of source text within the same unit, to which the glossary entry is relevant." I think it's wrong to limit this to the source text: - If the id is one of an annotation (which is likely), that same id can be on the target as well. So technically, we can't limit the pointing to just the source. - And obviously one may have glossary references specific to the target (why not?) using <mrk> elements that exist only in the target. So I would propose to change the text to: "points to a span of source or target text within the same unit, to which the glossary entry is relevant." Or: "points to a span of content within the same unit, to which the glossary entry is relevant." Cheers, -yves

Thanks Yves, I agree I will implement this as a minor correction/clarification. I did not mean to exclude target references, it was just a copy paste error from the candidates ref. Cheers dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Mon, Jan 6, 2014 at 9:43 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi David, all, The glossary ref attribute is defined as: "points to a span of source text within the same unit, to which the glossary entry is relevant." I think it's wrong to limit this to the source text: - If the id is one of an annotation (which is likely), that same id can be on the target as well. So technically, we can't limit the pointing to just the source. - And obviously one may have glossary references specific to the target (why not?) using <mrk> elements that exist only in the target. So I would propose to change the text to: "points to a span of source or target text within the same unit, to which the glossary entry is relevant." Or: "points to a span of content within the same unit, to which the glossary entry is relevant." Cheers, -yves --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

I implemented this and it will appear in the next printout On Mon, Jan 6, 2014 at 9:43 PM, Yves Savourel < ysavourel@enlaso.com > wrote: "points to a span of source or target text within the same unit, to which the glossary entry is relevant." Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone:  +353-6120-2781 cellphone: +353-86-0222-158 facsimile:  +353-6120-2734 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie

Hi David, all, During the discussion about the Translation Candidate annotation I've been looking at the Term annotation and noticed a change that, I think, we never discussed. The new note in the Term Annotation section says: [[ Note In this annotation type, the XLIFF Core ref attribute is intended to allow for referencing of terminology resources that are external to the XLIFF Document. The Glossary uses its own gls:ref to reference its corresponding spans in source content the other way round. ]] I see two issues: 1) When did we decided to limit term references to external URIs? The term annotation is about terminology, and terminology (as I've been sternly reminded several times by various people) is a lot more than "localization glossaries" as defined in the Glossary module. Therefore, it's perfectly valid for a future module or an extension to refer to some terminology data inside the document. I think I've pointed the Tilde's TAWS example of TBX in 1.2 several times: http://taws.tilde.com/xliff . Why would we suddenly forbid this? 2) Visibly the glossary module as no more link to the core: We don't use the term annotation to point to a glossary entry; and a glossary entry doesn't have to use a term annotation as its reference (glossary ref: "points to a span of source text within the same unit, to which the glossary entry is relevant.", which includes non-term annotations). So, IMO (and in line with separating core from modules when possible), we should avoid in the core to have references (other than examples) to modules. I won't fight for issue #2, but I think #1 is important to correct. Cheers, -yves

Yves, this is just a note and therefore informative and not normative. We do not forbid internal references other than modules, we just discourage them because cross-referencing of units and files is bad for streaming.. I believe that internal cross referencing of units and files should be banned at the general level.. The only admissible internal references should be within the same unit, group, or file. Having a TBX at the file level (as with the Tilde service) and referencing it from unit data is not ideal, IMHO should be discouraged but NOT forbidden, I am with you re this. That is why there is a note that non-normatively informs that the core ref is intended for external references rather than a PR or Constraint saying that is MUST NOT be used for internal pointing.. When introducing the refs in matches and glossary, I thought that the notes should explain to the implementer what is the intended difference between these possibly complementary reference mechanisms. I agree that modules should not be mentioned anywhere in the normative text of core. But mentioning them in notes is the same as using them in examples, i.e. non-normative just illustrating the relationship. While the implementer of the glossary module is free to use the core term annotation (it is neither forbidden nor mandated). The user of the core ref should primarily use it for external references unless they know what they are doing and are aware of the implementation consequences. Rgds dF On Jan 6, 2014 9:43 PM, "Yves Savourel" < ysavourel@enlaso.com > wrote: Hi David, all, During the discussion about the Translation Candidate annotation I've been looking at the Term annotation and noticed a change that, I think, we never discussed. The new note in the Term Annotation section says: [[ Note In this annotation type, the XLIFF Core ref attribute is intended to allow for referencing of terminology resources that are external to the XLIFF Document. The Glossary uses its own gls:ref to reference its corresponding spans in source content the other way round. ]] I see two issues: 1) When did we decided to limit term references to external URIs? The term annotation is about terminology, and terminology (as I've been sternly reminded several times by various people) is a lot more than "localization glossaries" as defined in the Glossary module. Therefore, it's perfectly valid for a future module or an extension to refer to some terminology data inside the document. I think I've pointed the Tilde's TAWS example of TBX in 1.2 several times: http://taws.tilde.com/xliff . Why would we suddenly forbid this? 2) Visibly the glossary module as no more link to the core: We don't use the term annotation to point to a glossary entry; and a glossary entry doesn't have to use a term annotation as its reference (glossary ref: "points to a span of source text within the same unit, to which the glossary entry is relevant.", which includes non-term annotations). So, IMO (and in line with separating core from modules when possible), we should avoid in the core to have references (other than examples) to modules. I won't fight for issue #2, but I think #1 is important to correct. Cheers, -yves --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Hi David, all, > Yves, this is just a note and therefore informative > and not normative. > We do not forbid internal references other than modules, > we just discourage them That note echoes the modified description in the definition of ref (section 4.3.1.27, which is normative): [[ When used in a term annotation, the URI value is referring to an external resource providing information about the term. ]] The word "external" should be remove. Cheers, -ys

Thanks Yves, I agree that it should be removed from the normative description, although the description does not contain a normative keyword. I will remove the word external from the description and it will be visible in the next printout. Rgds dF David Filip, Ph.D. ===================== cellphone: +353-86-0222-158 mailto: davidf@davidf.org www.davidf.org , http://www.linkedin.com/in/davidfatdavidf On Tue, Jan 7, 2014 at 11:52 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi David, all, > Yves, this is just a note and therefore informative > and not normative. > We do not forbid internal references other than modules, > we just discourage them That note echoes the modified description in the definition of ref (section 4.3.1.27, which is normative): [[ When used in a term annotation, the URI value is referring to an external resource providing information about the term. ]] The word "external" should be remove. Cheers, -ys

Thanks David. One editorial suggestion: Could we also have some text in the Conformance section that states that "Notes" are not normative? Because I doubt many people know that. We have this text: [[ As not all aspects of the XLIFF specification can be expressed in terms of XML Schemas, conformant XLIFF Documents MUST also comply with all relevant elements and attributes definitions, normative usage descriptions, and Constraints specified in this specification document. ]] And notes are nested in those definitions, usage descriptions, etc. It would be clearer to say for example: [[ As not all aspects of the XLIFF specification can be expressed in terms of XML Schemas, conformant XLIFF Documents MUST also comply with all relevant elements and attributes definitions, normative usage descriptions, and Constraints specified in this specification document. Notes are not normative. ]] Ideally normative and non-normative text should be in different colors (like black and blue), so everyone is clear about it. I'm not suggesting we do this, but it would make reading so much clearer. Cheers, -ys From: David Filip [ mailto:davidf@davidf.org ] Sent: Wednesday, January 8, 2014 3:11 AM To: Yves Savourel Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] term annotation Thanks Yves, I agree that it should be removed from the normative description, although the description does not contain a normative keyword. I will remove the word external from the description and it will be visible in the next printout. Rgds dF David Filip, Ph.D. ===================== cellphone: +353-86-0222-158 mailto:davidf@davidf.org www.davidf.org, http://www.linkedin.com/in/davidfatdavidf On Tue, Jan 7, 2014 at 11:52 PM, Yves Savourel <ysavourel@enlaso.com> wrote: Hi David, all, > Yves, this is just a note and therefore informative > and not normative. > We do not forbid internal references other than modules, > we just discourage them That note echoes the modified description in the definition of ref (section 4.3.1.27, which is normative): [[ When used in a term annotation, the URI value is referring to an external resource providing information about the term. ]] The word "external" should be remove. Cheers, -ys

Yves, although I though that it is common knowledge among standard consumers that notes, warnings, and examples are not normative, I do not think there is harm in stating that explicitly. Instead of the conformance section, I would add it in the intro where it says what parts are normative, I will be be back with details.. Cheers dF David Filip, Ph.D. ===================== cellphone: +353-86-0222-158 mailto: davidf@davidf.org www.davidf.org , http://www.linkedin.com/in/davidfatdavidf On Wed, Jan 8, 2014 at 11:30 AM, Yves Savourel < ysavourel@enlaso.com > wrote: Thanks David. One editorial suggestion: Could we also have some text in the Conformance section that states that "Notes" are not normative? Because I doubt many people know that. We have this text: [[ As not all aspects of the XLIFF specification can be expressed in terms of XML Schemas, conformant XLIFF Documents MUST also comply with all relevant elements and attributes definitions, normative usage descriptions, and Constraints specified in this specification document. ]] And notes are nested in those definitions, usage descriptions, etc. It would be clearer to say for example: [[ As not all aspects of the XLIFF specification can be expressed in terms of XML Schemas, conformant XLIFF Documents MUST also comply with all relevant elements and attributes definitions, normative usage descriptions, and Constraints specified in this specification document. Notes are not normative. ]] Ideally normative and non-normative text should be in different colors (like black and blue), so everyone is clear about it. I'm not suggesting we do this, but it would make reading so much clearer. Cheers, -ys From: David Filip [mailto: davidf@davidf.org ] Sent: Wednesday, January 8, 2014 3:11 AM To: Yves Savourel Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] term annotation Thanks Yves, I agree that it should be removed from the normative description, although the description does not contain a normative keyword. I will remove the word external from the description and it will be visible in the next printout. Rgds dF David Filip, Ph.D. ===================== cellphone: +353-86-0222-158 mailto: davidf@davidf.org www.davidf.org , http://www.linkedin.com/in/davidfatdavidf On Tue, Jan 7, 2014 at 11:52 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi David, all, > Yves, this is just a note and therefore informative > and not normative. > We do not forbid internal references other than modules, > we just discourage them That note echoes the modified description in the definition of ref (section 4.3.1.27, which is normative): [[ When used in a term annotation, the URI value is referring to an external resource providing information about the term. ]] The word "external" should be remove. Cheers, -ys

In the Introduction there was this emphasized paragraph: All text is normative unless otherwise labeled. I have tentatively expanded the wording of this paragraph as follows All text is normative unless otherwise labeled. The following common methods are used for labeling portions of this specification as informative and hence non-normative:   Appendices marked as "(Informative)" in Title,  Notes (sections with the "Note" Title),  Warnings (sections with the "Warning" Title),  Examples (mainly example code listings but also any inline examples or illustrative exemplary lists in otherwise normative text),  Schema and other artifacts listings (the corresponding artifacts are normtive, not their listings). I hope that this or improved wording can be approved in the meeting on January 14 Thanks and regards dF David Filip, Ph.D. ===================== cellphone: +353-86-0222-158 mailto: davidf@davidf.org www.davidf.org , http://www.linkedin.com/in/davidfatdavidf On Wed, Jan 8, 2014 at 2:06 PM, David Filip < davidf@davidf.org > wrote: Yves, although I though that it is common knowledge among standard consumers that notes, warnings, and examples are not normative, I do not think there is harm in stating that explicitly. Instead of the conformance section, I would add it in the intro where it says what parts are normative, I will be be back with details.. Cheers dF David Filip, Ph.D. ===================== cellphone: +353-86-0222-158 mailto: davidf@davidf.org www.davidf.org , http://www.linkedin.com/in/davidfatdavidf On Wed, Jan 8, 2014 at 11:30 AM, Yves Savourel < ysavourel@enlaso.com > wrote: Thanks David. One editorial suggestion: Could we also have some text in the Conformance section that states that "Notes" are not normative? Because I doubt many people know that. We have this text: [[ As not all aspects of the XLIFF specification can be expressed in terms of XML Schemas, conformant XLIFF Documents MUST also comply with all relevant elements and attributes definitions, normative usage descriptions, and Constraints specified in this specification document. ]] And notes are nested in those definitions, usage descriptions, etc. It would be clearer to say for example: [[ As not all aspects of the XLIFF specification can be expressed in terms of XML Schemas, conformant XLIFF Documents MUST also comply with all relevant elements and attributes definitions, normative usage descriptions, and Constraints specified in this specification document. Notes are not normative. ]] Ideally normative and non-normative text should be in different colors (like black and blue), so everyone is clear about it. I'm not suggesting we do this, but it would make reading so much clearer. Cheers, -ys From: David Filip [mailto: davidf@davidf.org ] Sent: Wednesday, January 8, 2014 3:11 AM To: Yves Savourel Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] term annotation Thanks Yves, I agree that it should be removed from the normative description, although the description does not contain a normative keyword. I will remove the word external from the description and it will be visible in the next printout. Rgds dF David Filip, Ph.D. ===================== cellphone: +353-86-0222-158 mailto: davidf@davidf.org www.davidf.org , http://www.linkedin.com/in/davidfatdavidf On Tue, Jan 7, 2014 at 11:52 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi David, all, > Yves, this is just a note and therefore informative > and not normative. > We do not forbid internal references other than modules, > we just discourage them That note echoes the modified description in the definition of ref (section 4.3.1.27, which is normative): [[ When used in a term annotation, the URI value is referring to an external resource providing information about the term. ]] The word "external" should be remove. Cheers, -ys

On Fri, Jan 10, 2014 at 1:17 PM, David Filip < davidf@davidf.org > wrote:  Appendices marked as "(Informative)" in Title, Just changing the proposed first item in the listing of non-normative stuff: Appendices and sections marked as "(Informative)" or "Non-Normative" in Title, The resulting proposed paragraph is: All text is normative unless otherwise labeled. The following common methods are used for labeling portions of this specification as informative and hence non-normative:   Appendices and sections marked as "(Informative)" or "Non-Normative" in Title,  Notes (sections with the "Note" Title),  Warnings (sections with the "Warning" Title),  Examples (mainly example code listings but also any inline examples or illustrative exemplary lists in otherwise normative text),  Schema and other artifacts listings (the corresponding artifacts are normtive, not their listings). David Filip, Ph.D. ===================== cellphone: +353-86-0222-158 mailto: davidf@davidf.org www.davidf.org , http://www.linkedin.com/in/davidfatdavidf

Just noting that you did the edit in one of the recent commits Thanks for it dF David Filip, Ph.D. ===================== cellphone: +353-86-0222-158 mailto: davidf@davidf.org www.davidf.org , http://www.linkedin.com/in/davidfatdavidf On Wed, Jan 8, 2014 at 10:10 AM, David Filip < davidf@davidf.org > wrote: Thanks Yves, I agree that it should be removed from the normative description, although the description does not contain a normative keyword. I will remove the word external from the description and it will be visible in the next printout. Rgds dF David Filip, Ph.D. ===================== cellphone: +353-86-0222-158 mailto: davidf@davidf.org www.davidf.org , http://www.linkedin.com/in/davidfatdavidf On Tue, Jan 7, 2014 at 11:52 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi David, all, > Yves, this is just a note and therefore informative > and not normative. > We do not forbid internal references other than modules, > we just discourage them That note echoes the modified description in the definition of ref (section 4.3.1.27, which is normative): [[ When used in a term annotation, the URI value is referring to an external resource providing information about the term. ]] The word "external" should be remove. Cheers, -ys