hasParticipant should not be described as an "abstract" property and should be limited to agents

[rjyounes]

A scope note on hasParticipant says: "This is intended as an abstract property. Only its subproperties will be directly used."

Now that hasParticipant rather than isConnectedTo is the recommended property connecting a temporal relation to the things it relates, I have been asserting it directly when none of the subproperties are suitable. This comment should be removed.

In addition, the scope note on TemporalRelation: "Note that 'participant' does not imply agency; a non-sentient being can be [sic] participate in a temporal relation. For example, both a person and a house could be participants in a hypothetical relation 'lives at.'" should also be added to the property itself.

For the record, I still balk every time I use hasParticipant with a non-sentient object, and I am finding that this usage confuses some new ontologists and has to be explained. I don't think it's the right term. Participation is an active concept. A house doesn't participate in anything, as far as I'm concerned. It is acted upon but does not act.

If you look at dictionary definitions, while some of them can be bent out of shape to include non-agents, most of them clearly imply agency, and all the examples do as well:

Merriam-Webster: "to take part"; "your mother participates in this ambition", "...always participates in class discussions."

Cambridge: "to take part in or become involved in an activity"; example participants are Kate, he, countries, members, restaurants. ("Restaurants" here implies an organization rather than a place, I think.)

Dictionary.com: "to take or have a part or share, as with others"; participate in profits or a play.

Collins: "to have or take a part or share with others (in some activity, enterprise, etc.)"; used with you, he.

Britannica: "to be involved with others in doing something; to take part in an activity or event with others."; people, you, he, employees, women, audience, participating store (again, like restaurant above).

Oxford: "to take part in or become involved in an activity"; anyone, she, students, women, countries, employees.

Enough?

If we decide to make this change, we need a different property to serve the purpose of linking things to a temporal relation in a non-specific way. Our original isConnectedTo was preferable, but now we've repurposed it so need another.

[uscholdm]

Do you have a proposal for a change?

We had an extensive discussion on this a while back. In ontology circles, hasParticpant has been used in a more inclusive way than you like for many years, so it does not bother me at all. I prefer it. However, the examples you give do suggest there is a notion of activity in participation, in much of everyday speech.

[uscholdm]

The broader idea is 'to be involved in', which might or might not be 'active participation' (which BTW is redundant, in RY's view). An accurate alternative to hasParticipant ishasInvolvee. Any more acceptable ideas?

[hmoore-sa]

For the record, I still balk every time I use hasParticipant with a non-sentient object, and I am finding that this usage confuses some new ontologists and has to be explained.

For the record, I am one of these ontologists, and I had to have it explained to me, which Rebecca was kind enough to do. I agree with the idea that it doesn't have to be a sentient agent, but it sounds like it should be something with the ability to act, not just be passively included.

[rjyounes]

In ontology circles, hasParticipant has been used in a more inclusive way than you like for many years

I have mixed feelings about this argument. I like our terms to accord with the language our clients would use at least as much, if not more, than conforming to practice by other ontologists.

How about just involves? hasInvolvee doesn't really fit the bill of conforming to ordinary language use, since "involvee" is not a word. :)

[uscholdm]

involves is not a bad option.

[uscholdm]

I like our terms to accord with the language our clients would use at least as much, if not more, than conforming to practice by other ontologists

That makes sense.

[dylan-sa]

Limiting the range of hasParticipant to agents (either formally with rdfs:range or informally with a note about the intention) makes sense to me. I agree w/ Michael that there are other notions of participation--e.g., Plato used to talk about inanimate things like tables "participating" in the form of Table-ness. However, I think the concept that accords more with the standard dictionary definition makes more sense for gist.

Regarding the related issue of TemporalRelation, I see pros and cons w/ different predicates:

• hasParticipant - Potentially confusing in the way @rjyounes describes, given its ordinary implication of agency.
• isConnectedTo - Nice that it's general and wouldn't require adding a predicate to gist. Downside is that the predicate might be so general that it's just indicating something vacuously true--i.e., it might as well be isRelatedTo.
• involves - Seems to have more content than isConnectedTo, but would require a new predicate.
• hasTemporalRelatum - This would be a new predicate restricted to this specific purpose, but it avoids hasParticipant's clash w/ ordinary language and the risk of vacuity w/ something like isConnectedTo. Granted, it is jargony, which we typically try to avoid in gist; but since TemporalRelation is already a bit jargony, maybe it would be warranted in this case.

[rjyounes]

isConnectedTo has been re-purposed, so we can't bring it back with its former meaning.

I don't like hasTemporalRelatum for the reason you state. "Relation" is a standard word, "relatum" is not.

I am no longer thrilled with involves: too many other meanings, such as "baking a cake involves stirring."

I'd like to keep thinking; I haven't yet seen a satisfying option.

[justin2004]

At the moment I think gist:hasParticipant is really:

:hasRole/:playedBy

It is already playing out under gist:hasParticipant:

gist:hasRecipient
gist:hasParty
gist:hasGiver

Those are roles in the FrameNet sense of role.
"Each frame has a number of core and non-core FEs [Frame Elements] which can be thought of as semantic roles."

So I think it would be nice to consider adding those 2 primitives :hasRole and :playedBy to gist and then we could possibly formally define gist:hasParticipant as a prop chain axiom.

Here is a snippet from a construct query I use in the Data-Centric data layer that uses these proposals to gist:

 ?txn_node a gist:Transaction ;
   gist:actualEndDate ?txn_date_time ;
   gist:hasMagnitude [ a gist:Balance ;
                       gist:numericValue ?price ;
                       gist:hasUnitOfMeasure gist:_USDollar ] ;
   gistp:hasRole [ gistp:playedBy :_AcmeCo ;
                   gist:categorizedBy wd:Q2596417\#beneficiary ] ;
   gistp:hasRole [ gistp:playedBy ?sales_rep ;
                   gist:categorizedBy wd:Q685433\#sales-rep ]

[rjyounes]

See #695, which also raises the Role issue.

[uscholdm]

   gistp:hasRole [ gistp:playedBy :_AcmeCo ;
                   gist:categorizedBy wd:Q2596417\#beneficiary ] ;

It is rare in my experience to get enough utilitey from having instances of a Role class. The property is generally sufficient. E.g. for a loan we don't need borrower and lender classes, we just need properties such as hasBorrower and hasLender. The property hasParticipant is meant to be a superproperty of all these properties that are representing roles.

[uscholdm]

Limiting the range of hasParticipant to agents (either formally with rdfs:range or informally with a note about the intention) makes sense to me. I agree w/ Michael that there are other notions of participation--e.g., Plato used to talk about inanimate things like tables "participating" in the form of Table-ness. However, I think the concept that accords more with the standard dictionary definition makes more sense for gist.

I don't think we need or want a property whose range is for agents only. We want a property that is intended for use by non-agents is confusing. Rebecca's point is that using hasParticipant as the name for that property is a bad idea.

[justin2004]

@uscholdm Using an object prop like this

[ a :Transaction ;
  :hasBeneficiary :fred ;                                                                                                                  
  :hasBuyer :sally ]

is an option but here I list 3 reasons to consider letting a category instance do the work of expressing the kind of role (rather than letting the object property do the work).

[uscholdm]

@uscholdm Using an object prop like this

[ a :Transaction ;
  :hasBeneficiary :fred ;                                                                                                                  
  :hasBuyer :sally ]

is an option but here I list 3 reasons to consider letting a category instance do the work of expressing the kind of role (rather than letting the object property do the work).

I just responded to those three possible benefits.

[rjyounes]

CONCLUSIONS:

Re abstract property point: Soften scope note to read "This is typically, but not necessarily, treated as an abstract property by defining specific subproperties indicating the nature of the participation."

Re active participation: clarify with scope note that it goes beyond participants with agency.