Add Address as range of toPlace/fromPlace

[rjyounes]

Assigned to MarkW to explore and bring back next time.

[uscholdm]

Any enterprise that ships anything from tankers full of oil to post cards will have core class which is the event of sending something from somewhere to somewhere else. So we need an answer to the two questions:

1. where is the item coming from?
2. where is the item going to?

That is exactly what toPlace and fromPlace are for. What are different ways to answer this question?

• A postal or shipping service would typically use addresses for both.
• An oil tanker would come from a port to another port (e.g. in Platts)
• Inter-office delivery in large enterprise might deliver to individual rooms, and might not need to record the place of origin, if it is known who sent it.
• Uber and Lyft use addresses to indicate where the person goes, but an address is often not useful to indicate where a person is picked up from that a bit more messy.

We do not want lots of properties such as: toAddress/fromAddress and toPort/fromPort and toRoomNumber and fromRoomNumber. One property should suffice. A room number could be considered an address, where the room is the place.

This is easily handled by extending the range of toPlace and fromPlace to include Address. I cannot think of anything else that it might be. This does not seem controversial. Can anyone who objects to this explain the problem that this solution is likely to causes in a practical enterprise context?

If I was extending gist for this purpose, I would be annoyed by having to create a new property so I could answer the 'where do I sent this package to' question with an address, I would have to add a new property. That is bad.

A fall back option is to remove the range entirely.

[rjyounes]

I'm definitely opposed to removing the range altogether. I still have to ponder the main issue; meanwhile, here are some thoughts:

A port is a place, so there's no issue there. Regarding room, let's say I send something to room number 12. I am not sending something to the number 12, I am sending it to the room designated by the number 12. Address strikes me as parallel. This was Mark's point about Address being Content and we don't send something to Content. In ordinary English, sending something to an address is a loose way of saying that you are sending it to a place designated by the address. The larger question raised is the perennial one of whether we want the ontology to follow the looseness of ordinary language, or make distinctions that ordinary language glosses over because it uses context to disambiguate the various meanings. This is a constant balancing act that gets answered in different ways in different contexts. To play devil's advocate, consider the dozens of uses of the word "use" in English, and how it might be convenient for the ontology to encompass all that ambiguity in a single predicate so that people don't have the annoying task of making the requisite semantic distinctions, but clearly we wouldn't take things that far (at least I wouldn't). I would love to come up with a set of criteria for deciding when each approach is appropriate, but it's likely impossible to articulate and more a matter of gut feeling; an art rather than a science.

[rjyounes]

DECISION: Implement this change.

[marksem]

So the implementation will be to declare the range of toPlace to be (Address or Place)? Same for fromPlace?

[rjyounes]

Yes

[marksem]

Is this major, since it changes reasoning? @rjyounes @uscholdm @pwin
and is that ^^ ok b/c we are targeting 10.0.0 with the next release?

[rjyounes]

Yes, it is. We can move it to May since April is no longer a major release. I don't think you were present for that decision.