Should `gist:isConnectedTo` be symmetric?

[dylan-sa]

Intuitively, if x is connected to y, then y is connected to x. Does this hold for gist:isConnectedTo?

[rjyounes]

No. This property can be used to connect a temporal relation to the two (or more) things it's connected to. So you can have, say, a Marriage relationship that is connected to each of the people in the marriage. They are not necessarily connected to one another by the predicate.

[dylan-sa]

With the marriage relationship, I can see how :_Person_A gist:isConnectedTo :_Person_B might not hold. I was suggesting something different: that if :_Marriage_between_A_and_B gist:isConnectedTo :_Person_A, then :_Person_A gist:isConnectedTo :_Marriage_between_A_and_B. But maybe that's still not necessarily the case!

[rjyounes]

I think that's probably right. There's a nuance that should be discussed by the group.

[uscholdm]

Rebecca's description is accurate. The problem is the naming of the predicate. There used to be an inverse property called hasConnection (which is equally unhelpful, other rthan implying that the property is not symmetric. Those two predicate names give no hint of what direction means what. I made up my own convention to always use connectedTo FROM the 'main' entity (e.g. a Marriage) to some aspect or part of it (one of the spouses). That's how it is used in TemporalRelation.

We are unlikely to come up with a better name for the property, but we might want to tweak the definition if we can make it more clear.

[dylan-sa]

An additional thought after our 8/11 meeting: isSiblingOf is symmetric and isOlderSiblingOf isn't, but isOlderSiblingOf is still a subproperty of isSiblingOf. So even if we decided to make gist:isConnectedTo symmetric, it wouldn't preclude us from building asymmetric or antisymmetric subproperties.

[rjyounes]

Dan: usually creates subproperties, which are not always symmetric, so it should not be symmetric.
E..g., supercedes.

Michael: Historically, isConnectedTo was used for temporal relationships.

Do we need this property? Do we need to rename it?

Current definition: "A non-owning, non-causal, non-subordinate (i.e., peer-to-peer) relationship."
Dan: seems OK other than "peer-to-peer."

Can also be used directly - mechanical or physical connection between objects. ("Foot bone connected to the ankle bone.")
Rebecca: This isn't the same relationship as the temporal relationship one. Should have another predicate for this case.

Michael suggests using hasParticipant instead.
Rebecca: suggests agency, so doesn't cover all cases.

Dan's proposal:

• Leave isConnectedTo as is, except remove "peer-to-peer" in the definition
• Expand the restriction on TemporalRelation to allow hasParticipant OR isConnectedTo
• Add isConnectedTo domainIncludes TemporalRelation (Michael)

We all agree to:

• Whatever predicate (call it predicate X) links a TemporalRelation to the two or more things it's connected to is not symmetric (primarily because we define sub-properties that are not symmetric). [REVISION: This is false - see @dylan-sa's comment above. So in fact there is no point of common agreement.]

Open questions:

• Do we want predicate X to also apply to the foot bone/ankle bone case?

  • Rebecca: No, these are completely different relationships. The marriage partners are analogous foot and ankle bone, not the Marriage to each of the partners.

• In that case, do we want to define a new predicate for this physical/mechanical connection?

  • Rebecca: No, let's not define anything new until we have a use case that can guide the definition (e.g., is it symmetric?).

• Do we want predicate X to be used for network connections?

  • Rebecca: No, we already have a network model for these (NetworkNode, NetworkLink, and links). Even though these are not used in mscore, we can let mscore do whatever it does, it shouldn't determine gist usage.

• Do we want predicate X to be limited to temporal relations?

  • Rebecca: No, because it could apply to other abstractions that are not types as temporal relations.

• Should we keep the name isConnectedTo for predicate X, or rename it?

  • Rebecca: I prefer to rename it, since the current name is clearly confusing and causes misunderstanding.

• Can we find a better name?

• Should predicate X be symmetric (see @dylan-sa's remark: this is possible without the sub-properties being symmetric)?

  • Rebecca: depends in part on whatever new name we select.

[rjyounes]

@dylan-sa is absolutely right. So now we have nothing that we all agree on, sadly. We'll revisit in two weeks.

[DanCarey404]

I may have muddied the waters with an incorrect understanding. I found a blog post that says "We can’t assume that property characteristics are inherited – some are (e.g. functionality), some aren’t (e.g. transitivity and symmetry)." That would confirm Dylan's point. In which case, maybe we can and should make :isConnectedTo symmetric.

[justin2004]

I think you were right the first time, @DanCarey404 .

If :isX is a subProperty of gist:isConnectedTo and gist:isConnectedTo is symmetric
then
if I assert
:bob :isX :fred
the reasoner will emit
:bob gist:isConnectedTo :fred
and then it will emit
:fred gist:isConnectedTo :bob

So making gist:isConnectedTo symmetric would constrain uses (including sub props) of it.

I think my vote here is to delete gist:isConnectedTo and make a migration to transform usages of it to use owl:topObjectProperty instead.

[rjyounes]

@justin2004 That was my initial reasoning as well. The fallacy is that the reasoner will infer fred :isConnectedTo :bob only when the sub-property is symmetric. Given another, non-symmetric, sub-property, that inference would not be made. Therefore, the super-property is not symmetric. I think @dylan-sa's example is pretty incontravertible.

We do not assert owl:topObjectProperty in our RDF and I have never seen this done. According to the OWL 2 spec:

The object property with IRI owl:topObjectProperty connects all possible pairs of individuals.

It would therefore be both redundant and meaningless to assert this relationship between two individuals.

What we are looking for is a predicate specifically designed to connect reified relationships to the objects that partake in that relationship. I.e., we are looking for a predicate with some semantics, not something vacuous. We are trying to constrain the semantics by excluding many of the other cases where we would use English "connected to" (this was the foot/ankle bone discussion) but which are semantically quite different. I use isConnectedBy in my client ontologies where I have no need for a more specific super-property, and do not want to lose it, though I would prefer a clearer name.

[justin2004]

What we are looking for is a predicate specifically designed to connect reified relationships to the objects that partake in that relationship

That sounds like we just need to use gist:hasParticipant.

:someNAryThing gist:hasParticipant :bob .
:someNAryThing gist:hasParticipant :fred .

I don't think the comments on gist:hasParticipant require that the participants be aware they are participating.
And on that topic I think the proposal in #695 is relevant.

I think this:

:someNAryThing gist:hasParticipant :bob .
:someNAryThing gist:hasParticipant :fred .

is really shorthand for something like this:

:someNAryThing :hasRole [ :playedBy :fred ] ;
                            :hasRole [ :playedBy :bob ] .  

[uscholdm]

What we are looking for is a predicate specifically designed to connect reified relationships to the objects that partake in that relationship

That sounds like we just need to use gist:hasParticipant.

:someNAryThing gist:hasParticipant :bob .
:someNAryThing gist:hasParticipant :fred .

I don't think the comments on gist:hasParticipant require that the participants be aware they are participating. And on that topic I think the proposal in #695 is relevant.

I think this:

:someNAryThing gist:hasParticipant :bob .
:someNAryThing gist:hasParticipant :fred .

is really shorthand for something like this:

:someNAryThing :hasRole [ :playedBy :fred ] ;
                            :hasRole [ :playedBy :bob ] .  

I agree with this. I have seen hasParticipant in other upper ontologies used in a neutral non-agentive fashion. In chemistary, a reactant is what particpates in a chemical reaction. They are not agentive. This is common usage. https://byjus.com/chemistry/precipitation-reaction/