-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How we represent qualifiers in data model? #94
Comments
Also please note that there are concepts, for example in 713-10-41, in which some translation are marked as "qualifiers" whereas some other are regular parts of speech, like "adjective". Correct or anomaly? |
Sought clarification from IEC. |
I think this is more about our internal data structures rather than about presentation layer. |
The internal data structure also depends on intention, so let's wait for IEC confirmation. It might take some time since some are on holiday. |
From IEC:
Perhaps we have to mark this as legacy somehow. @skalee thoughts? |
To IEC: In this case how should we deal with this to-be-retired attribute? Perhaps in the model we keep it as a “legacy” free-text attribute, and in the user interface we show it with some warning (so people don’t enter this field in unless absolutely necessary? ping @strogonoff for thoughts too. |
Background (which you may know): “qualifier” just means it’s a construct that describes something (a thing or an action) and that can be removed from the sentence without messing up the grammar. These are some simple cases:
Qualifiers are often adjectives or adverbs, but other parts of speech could be used as qualifiers, especially if we are considering multi-word expressions (and vice-versa, sometimes an adjective does not act as a qualifier in a given sentence). In my view, the “qualifier” flag isn’t entirely useless. If I didn’t know it’s considered legacy, I’d be open to adding “qualifier” (or “modifier”, maybe even “premodifier” and “postmodifier”) marker in our concept model. My considerations in favor of the qualifier flag:
Considerations against:
|
If we are definitely retiring the qualifier, then we could do it the following way:
|
@strogonoff IEC is going to remove all "qualifier" attributes sometime in the future, because the new rules no longer allow it. So keeping "qualifier" as an extra attribute in the model won't be useful in the future; we don't have anyone to use it, and the maintenance burden would be on us.
Could we handle this in some way that also allows handling other legacy attributes? |
I see. We should probably switch to customizable schema for this, until then we have a couple options:
Those both apply to the concept as a whole, but technically the “qualifier” trait is one that should apply to the concept as opposed to particular designation🤔 |
Let's remove it now. From data analysis, usage of this attribute is very inconsistent. For example, these concepts have "qualifier" in term name, not in term attributes:
And there are many, many more like these. I presume some other concepts have their definitions reworked to clearly indicate that it's qualifier. We cannot rely on presence of that attribute. I suppose the best we can do is to auto-replace "qualifier" termattribute with "(qualifier)" in designation or in front of definition. And perhaps to add some entry in FYI List of terms which have "qualifier" attribute or similar. May be incomplete if some localized term doesn't match my query or does not use latin script.
produces:
|
If we can remove it I don’t have objections. If we need to keep it for faithful data representation then I suggest to use an option from my previous comment (if it’s not a problem that “qualifier” will be applied to the whole concept and not to particular designation) |
@skalee we can't "remove" this attribute now, we must retain this because it is part of the standardized content.
Qualifier is clearly an attribute, so we should extract that from the term/designation.
Maybe, or not. IEV manager says that the "qualifier" attribute (today) will transition to a sentence in "Notes" (in the future).
In #94 (comment) @skalee provided an example where the "qualifier" attribute only applies to English. @skalee are there any other instances that the "qualifier" attribute applies to a designation instead of a concept? If this is the only one I will ask IEC whether this particular one can be adjusted/fixed. |
My reasoning suggests that, interestingly enough, being a qualifier is a property of the concept, not a particular designation 🤔
Unless we can come up with an example of a single concept that has some designations that are qualifiers and others that are not (I couldn’t think of one).
(Whereas part of speech, abbreviation marker, etc. clearly belong to individual designations of that concept.)
… On 23 Jan 2021, at 2:34 AM, Ronald Tse ***@***.***> wrote:
@skalee we can't "remove" this attribute now, we must retain this because it is part of the standardized content.
From data analysis, usage of this attribute is very inconsistent. For example, these concepts have "qualifier" in term name, not in term attributes
Qualifier is clearly an attribute, so we should extract that from the term/designation.
And perhaps to add some entry in comments.
Maybe, or not. IEV manager says that the "qualifier" attribute (today) will transition to a sentence in "Notes" (in the future).
@strogonoff :
(if it’s not a problem that “qualifier” will be applied to the whole concept and not to particular designation)
In #94 (comment) @skalee provided an example where the "qualifier" attribute only applies to English.
@skalee are there any other instances that the "qualifier" attribute applies to a designation instead of a concept? If this is the only one I will ask IEC whether this particular one can be adjusted/fixed.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
(And if we move the qualifier marker from designation to the concept, that would be a lossless transformation—I’m willing to be corrected here.) |
I believe this logic is also supported by the document in @ronaldtse’s screenshot, which moves this aspect to the definition—which concerns the concept as a whole. |
I have asked IEC for confirmation on whether this attribute applies to the concept or designation. Our original question:
The IEV terminology manager has this to say regarding legacy attributes:
|
To me it looks like they could be in the middle of transition from attribute to something else. Maybe we should ask for clarification.
I have similar feeling. By definition, term attributes are relevant to designation. They want to turn them into notes, what suggests that qualifiers are actually meant to be relevant to concepts, or at least localized concepts. This suggests misuse of term attributes.
I'll investigate, though I'm not sure I'll find out anything — there is so much inconsistency. |
They already said that they will be doing the transition but it might take years to revise these terms.
Thanks, please post if you find any inconsistency so that the IEV team can fix them (if editorial) or report them to the term owner for revision. |
@ronaldtse This is really inconsistent… https://gist.github.com/skalee/e281031db37a1a08941f04ec1a7721af And I'm pretty sure I'll find even more when I improve the SQL query. "AC" term is quite interesting — qualifier in English or Polish whereas abbreviation in Portuguese or Spanish:
|
@ronaldtse Got a question — are these IEV spreadsheets exports from some tool or they work on them directly? I'm asking because perhaps some discrepancies like "qualifier" being either in term column or in attribs column could be coming from export tool issue. |
@skalee these exports are exported from Lotus Domino. It reflects the actual data. |
Thanks for bringing this up, I will create a new issue on 151-15-01. |
From IEC:
tl;dr:
@skalee @strogonoff we will need to adjust the concept model to accommodate these. Thanks! |
Re: term can be both "noun" and "adj", I will seek clarification since the definitions can differ, and therefore the concept should also. NOTE: This does not affect our current work, so this issue should proceed. Thanks. |
Requiring qualifiers to be strictly adjectives doesn’t make sense from linguistic point of view, since they aren’t always adjectives. A given vocabulary can impose that constraint, but I don’t think it generalizes across all vocabularies.
Furthermore, a designation can be (and often is) a multi-word expression, where each word belongs to its own part of speech.
That’s why part of speech is an optional property of a designation in Glossarist’s model. A designation is either a qualifier or not, but it may not have a single clear part of speech, especially if it is a phrase consisting of multiple words.
… On 29 Jan 2021, at 11:53 AM, Ronald Tse ***@***.***> wrote:
"qualifier" means each of its terms are considered to have a parts of speech "adj" according to the IEC revised rules (IEC Directives, Annex SK 3.1.3.6.2).
|
From https://en.wiktionary.org/wiki/qualifier#English:
Can we consider it as another part of speech (although in fact it's not)? Or maybe we need a separate field for that?
Qualifier examples:
Here is how they are displayed in Electropedia:
Feel free to move this issue to glossarist/concept-model if you find it more appropriate.
The text was updated successfully, but these errors were encountered: