Use of Person subclasses

[swartik]

The recent discussion around issues #422 and #431 make me wonder how subclasses of Person are intended to be used.

Most of these classes inherently require temporal qualifications for instance membership. Stalin was a Truman ally during WW II. Stalin was not a Truman ally during the Korean War. It seems a little strange to assert or infer Allied Person membership just because an individual bears an Ally Role at some point during the individual's existence.

The issue arises largely because description logics can't express temporal qualification. I'd like the equivalence assertion to be:

Person and ('bearer of' some ('Ally Role' and ('participates in' some (process and ('occupies temporal region' some 'temporal region'))))) and ('participates in' some process)

but I want the Person and the Ally Role to participate in the same process, and description logics can't specify that.

I propose the definitions of Person subclasses be rewritten. At a minimum, rewrite the definition for Allied Person as follows:

A Person who is the bearer of some Ally Role during some temporal region.

That's a shorthand for:

A Person who is the bearer of some Ally Role during some process that occupies some temporal region.

I grant that amount of detail may be too tedious for a CCO definition.

[alanruttenberg]

If I understand you correctly, you don't have to add temporal region. bearer-of is atemporal. The time aspect of it is handled in the existence of the role - use exists-at.

You are an allied person so long as you bear the ally role, and since it is specifically dependent you bears it as long as the role exists.
You can then say (in the data) that the ally role exists-at some temporal interval.

But note that Ally is relational. You are an ally to some other entity. So Ally role ought to be a relational role.

[swartik]

I need to explain this at length. I'll do it in the future. But for now, I want to bring up a separate-but-relevant matter. All the CCO ocumentation I've seen to date uses:

:role a obo:role ;
    obo:participates_in :process .
:process a obo:process ;
    obo:occupies_temporal_region :region .
:region a obo:temporal_region .

I am not aware of any CCO documentation that uses:

:role obo:exists_at :region .

Do CCO's gatekeepers have anything to say about preferring one pattern over the other?

[gregfowlerphd]

@alanruttenberg: I'm inclined to agree with you that Ally Role ought to be treated as a relational role. That is, by analogy with BFO's relational qualities, it ought to be treated as a role that specifically depends on, and hence inheres in, more than one independent continuant--or, to put it another way, as a role that has more than one bearer.

The problem, as I noted in a recent talk, is that the elucidation for role appears to rule out relational roles by requiring a role to have a single bearer. And it's also worth noting in this connection that definitions for subclasses of role in BFO-conformant ontologies seem never to invoke multiple bearers.

[swartik]

My point has to do with documentation, not semantics. I desire definitions that prescribe or at least suggest design patterns.

My difficulty is that a knowledge graph containing the triple:

:stalin a cco:AlliedPerson .

sure looks like it asserts Stalin is someone's ally. Not “was”. “Is”. A CCO-based knowledge graph that asserts someone to be a member of one of the Person subclasses needs to bear a role, lest the knowledge graph have a limited period of relevance. Conversely, a SPARQL query containing the pattern:

?ally a cco:AlliedPerson

had better require ?ally to bear a ccoAllyRole. At least, I wouldn't want to use the unqualified pattern to retrieve up-to-date data.

All this implies that anyone using a knowledge graph based on CCO:

• Has to be aware that roles can be temporally qualified.
• Has to understand the possible ways to express temporal qualification.
• Has to know how temporal qualification is expressed in that knowledge graph.

@alanruttenberg's comment suggests using exists-at:

:stalin obo:bearer-of :allyRole .
:allyRole a cco:AllyRole ;
    obo:exists-at :region .

The CCO documentation suggests linking the role to a process:

:allyRole obo:participates-in :allyProcess .
:allyProcess a obo:process ;
    obo:occupies-temporal-region :region .

It would be a mistake to expect SPARQL queries to account for both design patterns. What I propose is to amend the CCO definitions to clarify the pattern to use.