#271 irregularities in <gram> syntatic sugar variants
<gram> is a heavily used tag in dictionaries and has a set of other tags which are syntactic sugar of it. Life would be easier if these were more regular and better documented. For example, <gram> contains no reference to it's derived forms, which are derived in an irregular fashion.
(1) Either:
(A) Add a note to <gram> stating "<gen> is synonymous with <gram type="gender">. <number> is synonymous with <gram type="num">. <case> is synonymous with <gram type="case">. <per> is synonymous with <gram type="person">. <tns> is synonymous with <gram type="tense">. <mood> is synonymous with <gram type="mood">."
or
(B) Incorporate all of these examples in a rewritten discussion of the 'type'
(2) Add some form of explicit warning that the @types of 'gen' 'number' 'per' and 'tns' map to tags of different names. Could a schematron rule usefully catch issues such as this?
(3) Find some reference other than 'ISO WD 12 620' which I don't seem to be able to decode into an actual real document. A full bibliographic reference would be most excellent. A link to the full text better.
(4) Thought be given to whether <pos> is meant to be synonymous with <gram type="pos">, given it's mention on the <gram> page and it's lack of @type (if so, modify (1) appropriately)
(5) Rename the tags to match their @type values (and the standard)
(*) Quotes be added to the final examples in http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-number.html and http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-mood.html
Agree in principle, with further comments:
* <number> as synonymous with <gram type="num"> sounds pretty bad (the "number" vs. "num" contrast is used for a different purpose in the Guidelines), so I suggest changing that too; it appears in the example in
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-number.html [possibly, this is Stuart's (5), if I understand correctly]
* I'm not sure what the value of @type for <pos> could possibly be (with regard to (4));
* the reference to http://www.isocat.org should be promoted to the top of the reference page, perhaps, to address the accessibility issue: http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-gram.html
Added the quotes around attribute values in the examples, because that was an obvious typo.
Could not we try to systematize (recommend) the use of ISOCat identifiers as values for gram/@type?
That would not be a bad move. Except that parts of ISOCat can be a mess (tripled definitions, bad definitions, etc.), so there should either be some warning or maybe a pointer to an example feature selection.
Can I assume that the reference to "ISO WD 12 620" means ISO standard 12620 as found at http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=37243 ?
I've changed the reference to "ISO WD 12 620" to "ISO 12620". I've refrained from adding a URL as in Stuart's latest post, because I suspect the URL may refer only to ISO 12620:2009, which may be superceded.
The URL you should point to is: http://www.isocat.org/
Where all standardized and private data categories are maintained, in accordance to ISO 12620.
Fixed. All references now point to isocat.org.
As I understand it, the proposal is to make explicit that (a) all @type values on <gram> should correspond with existing identifiers in ISO 12620 (b) that shortcuts for some (all?) of those values be provided, using the same identifiers and explicitly stating their synonymy.
I am happy with this, but it begs two questions : why bother with the short cut elements? why not rename the @type attribute to (say) @isocat ?
Where are we in terms of implementation?
Discussing this issue with the ISOCat colleagues, it appears that there is a recommended mechanisms for this. I introduce a ticket for this.
I'd be reluctant to change @type to @isocat because of backwards-compatibility, and because of the paradigm <x type="y"> is such a common and expected method of doing syntactic-sugar stuff.
I agree with Martin on breaking backwards compatibility. On the other hand, I believe @type is always free-form, whereas certain other attributes (like @xml:lang, @date, and @date-iso) take values defined by outside standards. So I'm sympathetic to having an attribute dedicated to an ISO WD 12620 value.
I think one thing we don't want to do is scare people away by forcing them to look for values of @type in the ISOcat. It's not really the source of ultimate knowledge and agreement, it's *just* an external reference repository. So I'd suggest keeping @type as is, for people who want to keep it informal (at least until they gather the necessary courage), and using the dcr: namespace for DCR references. Probably this is what Laurent refers to.
Convergence with ISOcat is clearly the best long-term solution for this, but that's going to break things for some people. Maybe we need to signal future planned convergence in the text and revisit the issue in a major release?
I suggest that this change is made in the context of implementing the new feature request for the standard reference to ISOCat: https://sourceforge.net/tracker/?func=detail&aid=3432520&group_id=106328&atid=644065
Define new class to provide dcr:datcat (cf https://sourceforge.net/tracker/?func=detail&aid=3432520&group_id=106328&atid=644065\) and add all model.gramPart elements to it.
My attempts to understand exactly what's going on with ISO 12620 led me to create: http://en.wikipedia.org/wiki/ISO_12620
It appears to me that we should close this ticket. It seems to have evolved into another ticket, and I don't see anything left on this ticket that's actionable.
Closed: see https://sourceforge.net/tracker/?func=detail&aid=3432520&group_id=106328&atid=644065