Semantics graph updates

[wcroft]

Here are the changes to the semantics graph, and also to the construction graph. Almost all of the major issues have to do with the semantic concepts associated with the modification function. Some of these are additions/revisions to what was on my Semantics trees. The rest are just minor fixes.

The first major issue has to do with the fact that the following CCs are cxn CCs in Morphosyntax:

• intensifier, downtoner, comparative form, superlative form, measurement, complementaries, antonyms

I had previously told Arthur to change all of these to semantic CCs (renaming 'comparative/superlative form' to 'comparative/superlative degree). But we really need both sem and cxn CCs. The CC names in the book are more commonly used as terms for forms, so they should be restored as cxn CCs as in Morphosyntax, namely:

• cxn:intensifier, cxn:downtoner, cxn:comparative-degree, cxn:superlative-degree, cxn:measurement SubtypeOf cxn:admodifier
• cxn:complementaries, cxn:antonyms SubtypeOf cxn:adjective

The semantic concepts are all new. For degree subtypes, this is basically just a (re)naming exercise:

• NEW: intensifying, downtoning, comparative degree, superlative degree, measuring SubtypeOf degree
• These are all FunctionOf the corresponding cxn CCs (now restored).

For the semantic counterpart CCs for complementaries and antonyms, they are treated as subtypes of a new attribute, sem:scale:

• NEW: scale AttributeOf property
• NEW: gradient, categorical SubtypeOf scale
• sem:gradient FunctionOf cxn:antonyms
• sem: categorical FunctionOf cxn:complementaries

Another major change is to introduce a superordinate sem CC, sem:mensural-concept, which subsumes all the mensural construction subtypes:

• NEW: mensural concept
• mensural concept SubtypeOf event
• measure, container, arrangement, group, piece, species SubtypeOf mensural concept, NOT SubtypeOf event
• sem:mensural-concept FunctionOf cxn:mensural-term

Another major change is to introduce the major aspectual attributes to the various non-property event concepts in Tree 1 of my Semantics Trees:

• cardinal numeral, vague numeral, amount, proportional quantifier, distributive quantifier, ordinal numeral, mensural concept Attribute stative
• cardinal numeral, vague numeral, amount, proportional quantifier, distributive quantifier, ordinal numeral, mensural concept Attribute transitory

Among other things, this allows a user to create a subgraph with all and (almost) only the typical modifying semantic concepts in the visualization, by selecting either sem:stative or sem:transitory, do one Expand Upward, and then Remove Unselected. (sem:stative also brings in properties and (transitory) states, which is desirable; sem:transitory excludes properties and brings in actions, which is not desirable, but for consistency both attributes should be applied to all the event concepts in Tree 1.)

Another significant change is to introduce sem:external-cause and sem:affectee, which I had tentatively included in my Semantic Tree 3. I'm introducing them to simplify the graph a bit, and because it anticipates what I hope is an overhaul of the analysis of semantic roles and argument structure constructions (to replace Haspelmath's exemplar approach).

• NEW: external cause SubtypeOf semantic role
• agent, instrument, force, comitative, causer, causee, cause SubtypeOf external cause, NOT SubtypeOf semantic role
• external cause RoleOf qualitative event, spatial event, transfer event, experiential event
• agent, instrument, force, comitative, causer, causee, cause NOT RoleOf qualitative event, spatial event, transfer event, experiential event
• NEW: affectee SubtypeOf semantic role
• beneficiary, maleficiary SubtypeOf affectee
• affectee RoleOf qualitative event, spatial event, transfer event, experiential event
• beneficiary, maleficiary NOT RoleOf qualitative event, spatial event, transfer event, experiential event (the last was not previously included)

The rest are minor fixes:

• base event PartOf causal structure, NOT SubtypeOf event
• initiator, endpoint SubtypeOf central participant, NOT SubtypeOf participant
• antecedent, subsequent roles SubtypeOf peripheral participant, NOT SubtypeOf participant
• (transitory) state, property Attribute monovalent
• location (=figure-ground spatial) relation Attribute bivalent
• property, killing/injuring event, damage event, contact by impact event SubtypeOf qualitative event
• ingestion event SubtypeOf experiential event

Finally, I think we should change the preferred names of two CCs as follows:

• possession relation preferred name to possession
• location relation preferred name to figure-ground spatial relation

All these fixes are represented on my Semantic and Construction trees. These trees are now on Github.

[arthurlorenzi]

Made all of the proposed changes. Just two things:

• I've restored the comparative and superlative degree construction concepts as comparative and superlative term, similarly to the glossary and to avoid any confusion between the semantic and construction CC. Is that OK? Or should all four be 'degree'?

• We now have sem:measure and sem:measuring. I understand they are different, but the names are quite similar. We can keep it, but it could be a good idea to turn measuring into something like 'measuring degree'.

[wcroft]

I’ve been away two weeks and there’s a lot I have waiting for me here, so it’ll take a while for me to get back into this. Here are responses to your comments:

On Jul 1, 2024, at 4:47 PM, arthurlorenzi @.***> wrote:

Made all of the proposed changes. Just two things:

I've restored the comparative and superlative degree construction concepts as comparative and superlative term, similarly to the glossary and to avoid any confusion between the semantic and construction CC. Is that OK? Or should all four be 'degree’?

The CC names in the original Glossary are cxn:comparative form, cxn:superlative form, not ’term’. I think we should stick with the Glossary names for consistency. We now have sem:measure and sem:measuring. I understand they are different, but the names are quite similar. We can keep it, but it could be a good idea to turn measuring into something like 'measuring degree’. I see the issue. But it’s not really degree; it’s the actual measure, e.g. six centimeters. Also, I used the -ing form for the other semantic CCs -- these are all new terms, not in the book. Or we could go with sem:calibrating -- a calibratable scale is a scale for which a quantifiable measurement is available (i.e. length, but not happiness).

Bill

[arthurlorenzi]

It was my bad: I had already name them "form", not "term". So this is correct.

Regarding sem:measuring, I think sem:calibrating also works. But I think what made it confusing to me was exacly the POS: we have sem:degree but all of its subtypes have the -ing form. But this is definitely something minor and with the definitions the issues might be completely mitigated.

Something else I've just noticed is that we don't have a very explicit relation between sem:degree and sem:scale. I see two ways of making that clearer, if you agree:

• Create a new CC called sem:scalar-concept (or scalar property) as a subtype of sem:property-concept. Then, both sem:scale and sem:degree are attributes of sem:scalar-concept. Scalar concept is length, but not hapiness.
• Alternatively, we could also have a direct relation between the sem:degree and sem:scale, either associated or sem:degree being part of sem:scale. That would be like construing a scale as a (ordered) set of degrees.

Of course, we can also leave that for future versions.

[wcroft]

On Jul 2, 2024, at 9:35 AM, arthurlorenzi @.***> wrote:

It was my bad: I had already name them "form", not "term". So this is correct.

Regarding sem:measuring, I think sem:calibrating also works. But I think what made it confusing to me was exacly the POS: we have sem:degree but all of its subtypes have the -ing form. But this is definitely something minor.

I’m open to alternative terms, since these CCs were not in the glossary. If you don’t like the modifier -ing forms, we could use “intensification”, but then we’re still stuck with “downtoning”, and we can’t used “measurement” because that is the cxn CC in the Glossary. Something else I've just noticed is that we don't have a very explicit relation between sem:degree and sem:scale. I see two ways of making that clearer, if you agree:

Create a new CC called sem:scalar-concept (or scalar property) as a subtype of sem:property-concept. Then, both sem:scale and sem:degree are attributes of sem:scalar-concept. Scalar concept is length, but not hapiness. Most people use “scale” for both calibratable and non-calibratable scales. I would not want to introduce “scalar concept”. Alternatively, we could also have a direct relation between the sem:degree and sem:scale, either associated or sem:degree being part of sem:scale. That would be like construing a scale as a (ordered) set of degrees. Currently, I treated “degree” as AttributeOf “scale”. That’s fairly neutral. We could change this to PartOf, as you suggest. All of the specific values are points or regions on the scale, so can be construed as PartOf. In either case, the values are SubtypeOf degree.

Bill

[arthurlorenzi]

On the current .pdf "degree" was an AttributeOf "property", and just changed it to "scale". We can keep the names for now and revisit later after FunctionOf if someone else find them confusing.

[wcroft]

OK. I made the changes to the Semantics trees pdf. I can upload it but I can’t find where the folder is with the tree pdfs on GitHub, and I can’t find the link that Peter sent me for that folder. Peter, could you send me the link again?

Thanks, Bill

On Jul 3, 2024, at 3:29 PM, arthurlorenzi @.***> wrote:

On the current .pdf "degree" was an AttributeOf "property", and just changed it to "scale". We can keep the names for now and revisit later after FunctionOf if someone else find them confusing.

— Reply to this email directly, view it on GitHub https://github.com/comparative-concepts/cc-database/issues/5#issuecomment-2207341529, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGAWDPRNSKVFCUIZJEUAO33ZKRUKLAVCNFSM6AAAAABILIO6M2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBXGM2DCNJSHE. You are receiving this because you authored the thread.