search

TEIC / TEI

The Text Encoding Initiative Guidelines
https://www.tei-c.org
Other
269 stars 88 forks source link

sydb 2049 — on <altIdent> reduex #2334

Closed sydb closed 1 year ago

sydb commented 1 year ago

Note: I had an off-by-one error when transcribing some of the step numbers into the git commit comments. Sorry.

Also note that the content of <altIdent> is defined as name=NCName rather than key=teidata.xmlName due to TEIC/Stylesheets/issues/569.

hcayless commented 1 year ago

So...having both a model.indentInfo and a model.identInformation makes me want to run away screaming. Why?

sydb commented 1 year ago

I have no idea — I do not even know if you are unhappy with the names (in which case feel free to suggest different ones), or the idea that we need 2 classes.

sydb commented 1 year ago

But in any case it is not properly passing tests, yet. Still working …

sydb commented 1 year ago

Fixed. (All tests pass in docker container on my system.)

lb42 commented 1 year ago

Howsabout calling it model.identSynonyms for clarity?

sydb commented 1 year ago

@lb42 — Which one, the one that has <gloss>, <equiv>, and <altIdent>, or the one that has only <gloss> and <equiv>?

Either way, much better than my model.identInfo[rmation], and perhaps even better than the model.identEquiv, thank you.

lb42 commented 1 year ago

I meant the one that has altIdent but lookibg closer at this thread i dont see much justification for havibg two classes anyway

sydb commented 1 year ago

Would you use one class and add <altIdent> manually to the 7 elements that need it in their content model? (Remember, the point of the PR is to get <altIdent> out of the content models of the other 6 elements.) In any case, I like model.identSynonyms much better for the one with <altIdent> (currently, and kinda uselessly, called model.identInfo in this branch). Unless someone objects or comes up with something better, I plan to change it to that name later today.

lb42 commented 1 year ago

So the issue is whether otslikely there might ever be a sevond such element which shd appear in the same places as altIdent. I think probly not.

sydb commented 1 year ago

OK, then, it looks like we have 2 suggestions on the table; I will also add the no-class approach, the reverse approach, and the no-subclass approach for completeness.

proposal one (classes all the way down)

model.identEquiv = gloss | equiv   [used by 6 elements]
model.identSynonyms = altIdent | model.identEquiv   [used by 7 elements]

proposal two (one class +altIdent)

model.identEquiv = gloss | equiv   [used by 6 elements]
( model.identEquiv | altIdent )   [used by 7 elements]

proposal three (no classes approach)

( gloss | equiv )   [used by 6 elements]
( gloss | equiv | altIdent )   [used by 7 elements]

proposal four (no sublcass approach)

model.identEquiv = gloss | equiv   [used by 6 elements]
model.identSynonyms = gloss | equiv | altIdent   [used by 7 elements]

proposal five (reverse of proposal two, sort of)

( gloss | equiv )   [used by 6 elements]
model.identSynonyms = gloss | equiv | altIdent   [used by 7 elements]

I personally like proposals one and four (i.e., defining 2 classes), but honestly would be happy with any of the above. I think @lb42’s observation that one of the motivating factors for using classes — to allow users to easily add a new element — is not really apropos (because not likely to be used by anyone) is accurate.

ebeshero commented 1 year ago

@sydb I like your proposal one: it seems easiest to work with what you've already prepared, considering we're basically dithering over the model names.

lb42 commented 1 year ago

The trouble with the TEI class system is that some classes are "structural" (i.e. they provide a convenient means of grouping elements likely to appear together in a content model) and others are "semantic" (i.e. they group elements which have some semantic property in common. indicated by the name of the class). Usually, one implies the other, but in this case it doesn't seem to me that a "gloss" is a synonym to the extent that an altIdent is: even less so for equiv. This maybe is lily-gilding, but I'd rather see a class named model.identLike containing gloss and equiv, used in content models. I also think altIdent is enough of a special case that it should be explicitly referenced in content models where it's allowed, but if you want to make a special class for it model.identSynonym seems right. Though I will give five shillings (old money) to the first person who actually finds a use for such a class in the wild.

ebeshero commented 1 year ago

I admit was a little bothered by identSynonyms being inclusive of <gloss>, too, and was sort of stretching out the idea of “synonymous” to make it work conceptually as the larger model.

We seem to need

We should have a name that works for whole group. We probably don’t need a class just for altIdent that says, “I’m a synonym.”

How about:

?

bansp commented 1 year ago

Let me just register my amazement that equiv is in a single class with gloss -- I've just looked at the examples of gloss and find it hard to imagine that equiv would have anything to do with that, even potentially. I've gone through the discussion out of curiosity (Lou's remarks often make me do that), and I kept thinking that, at least from the semantic point of view, I could put equiv and altIdent together, but gloss? And then I looked at examples of gloss and started wondering about the structural paring of gloss and equiv, and that seems strange as well. (Of course, it's good to have them under category but I never thought that they came from a single element class). This is not meant to derail the current process, but I thought I'd just register my impressions in case an outsider view could help in any way.

sydb commented 1 year ago

So @lb42 is in favor of proposal two with a different name for the class. @ebeshero is in favor of proposal one or four (can’t tell which) with different names. Seems like @bansp would prefer proposal three or a new arrangement that grouped only <equiv> and <altIdent> in a class.

As I said, I do not care much, and consider this decision pretty low impact on the TEI world. At the moment I am leaning towards proposal two on the theory that we only have to dream up 1 class name for it. As for that name, I shy away from @lb42 ’s proposed “model.identLike” due to the implication that <ident> would be a member. It is not a given that all *Like classes include the element that matches their name, but the vast majority (43 of 53) do.

“*Like” class memebership

Using current version of this branch.

does NOT contain its own so-named element

only 1 member, named the same

contains its own so-named element

bansp commented 1 year ago

I'm not sure if label myself as "option 3". Let me explain where I come from to this. Part of the reason I spoke up is equiv, which had recently made me go back all the way to 2012 for archived Council discussions on the interplay between equiv and att.datcat, also in view of what I would like to propose in the 'datcat' PR. In short, they overlap, or they are in what structuralism would call complementary distribution, with the same function (from my perspective) which is basically to provide an arc to a node, and to label that arc by implication from the element/attribute name. From that perspective, I would group equiv and altIdent because the latter performs roughly a very similar ontological (or ontology-related) function, except while equiv points at an object, altIdent points at a literal, a label. But gloss is just a piece of annotation (in the sense of a: in RNG), so that's why I felt uneasy seeing it grouped with one of the "arc-like" elements, but not another. I could more or less clearly imagine the pragmatism of grouping gloss and equiv in tagdocs and in taxonomies (they are just handy to have around, together). But when I looked at those examples of the use of gloss I referenced above (and it's sometimes used as an empty element! oops :-)), I started doubting the pragmatism of grouping gloss and equiv -- the fact that they co-occur in elementSpec (etc.) started looking like a plain coincidence rather than any structural regularity (= regularity which one would expect to have a structural explanation). So since this seems to be in a bit of a flux, I thought I would share my uneasiness, in case it could be useful :-)

hcayless commented 1 year ago

I agree with @bansp.

ebeshero commented 1 year ago

I like how @bansp points out the strangeness of the grouping of equiv and gloss. It seems surely a matter of convenience for processing that we classify this way. I wish I knew what to recommend. If the only goal is to successfully build the Guidelines, the classes applied shouldn’t matter. They’re just a convenient cog in a machine that we keep tinkering with and repairing. If they are more than that, they’re for humans to read—but maybe these classes don’t need to be any more meaningful than altIdentClass and altIdentSubclass. Or maybe we don’t need them at all. I wonder if processing requirements might somehow be made their own meaningful classes so we aren’t straining words like synonym or equivalent or annotation when we really mean, process exclusively or inclusively.

jamescummings commented 1 year ago

Hi all,

Coming to this very late and reading through the issue when I got to @sydb's proposals, I instantly thought Proposal 1 was the right TEI'ish way to do things. It seemed a good balance between leveraging the class system and clarity about what was going on. But then I too wondered at what <equiv> and <gloss> were doing in the same class together. So I went and read some of our history in this area, particularly https://github.com/TEIC/TEI/issues/1079 were one @lb42 notes the 'gloss-like' qualities of <equiv> and <altIdent> but not <gloss>. On reflection I think separating <gloss> from a class which has <equiv> and <altIdent> (if and only if useful... I'm sceptical that there will be much need to class-based modifications or new membership there) would make the most sense.

ebeshero commented 1 year ago

I think the changes you made answer my questions, so I'm happy with this. Can someone test this locally?

HelenaSabel commented 1 year ago

I tested it locally and the tests passed, so I think @sabineseifert can click the green button safely :)