hasCommunicationAddress has too restrictive a domain

[marksem]

hasCommunicationAddress has domain of Person or Organization. Don't other things receive communications at addresses? E.g. computing services? Are we really saying the only things that can ever have communication addresses are people and organizations? Seems way too restrictive.

[uscholdm]

Interesting observation. I guess anything that is 'agentive' might have a communication address so you can inform it or tell it what to do - such as a software program that you send messages to. We may or may not want to exclude this kind of thing, for our purposes. It is not clear to me at the moment which way to go.

[marksem]

I think this is a case in point of the more general problem of overuse of range/domain.

Generally, I think gist should avoid domains & ranges except where they will/must be true.
e.g.

• hasPhysicalLocation has a range of Place; this is fine since any object of this relation must be a Place by the meaning of the predicate.

Other than cases where a domain/range must be true, I think domains and ranges should be avoided to allow legitimate reuse. I'd rather see gist mostly restrict properties locally, within class definitions.

[justin2004]

At minimum I think it makes sense to remove the domain on gist:hasCommunicationAddress and add gist:domainIncludes with the following:
gist:LivingThing gist:Organization gist:System gist:Component gist:Equipment

Those look like all the agentive flavored things that would participate in communications.

[uscholdm]

I suggest using Person, not LivingThing. WE don't have to worry about sending non-humans communications,

[justin2004]

@uscholdm , YET! ;)

[uscholdm]

@uscholdm , YET! ;)

It would be fun to be forced to expand the domainIncludes to include maybe whales and chimps, but I'm not holding my breath.

[rjyounes]

I like dropping the domain. Not sure about a lengthy list of domainIncludes which will probably have some omissions. Person and Organization are probably the most likely uses cases, so we could just include them. IMO domainIncludes and rangeIncludes don't need to try to be exhaustive.

[uscholdm]

IMO domainIncludes and rangeIncludes don't need to try to be exhaustive.

Agreed. It should include the one most likely to be used most often.

[Jamie-SA]

domainIncludes and rangeIncludes don't need to try to be exhaustive.

That wording would be good to have in their definitions/scopenotes. It kinda says that now, but not as direct and obvious.

[rjyounes]

@Jamie-SA I like that. I've added it to issue #736, which also deals with annotations on those properties.

[rjyounes]

DECISION: Remove domain, add domainIncludes to Person and Organization. This is a major change because it affects inferencing into the classes.