Add gist:refersTo object property

[DanCarey404]

Proposal: Add gist:refersTo data property, with a domain of gist:Content. Definition: "The Subject content indicates, signifies, or points to the Object."

Background: I was looking for a way to associate an Address (which is content) with a GeoRegion. It is improper to say "content is located in a GeoRegion". I considered using the extant gist:isAbout property. But that didn't seem quite right. After a bit of Teams discussion, I decided to propose gist:refersTo as a new property.

Example:

:_1617Humboldt a gist:Address . :_RussianRiverWatershed a gist:GeoRegion . :_Steven gist:residesAt :_1617Humboldt . :_1617Humboldt gist:refersTo :_RussianRiverWatershed .

[uscholdm]

This is a peculiar example. How can a street address refer to a watershed?

indicates, signifies, or points to

It might be a good idea to have a property that means "indicates, signifies, or points to" but those words are not what comes to mind by the phrase 'refers to'

Dave often says a physical address corresponds to a routing algorithm to a physical place (which is close to 'points to')

Michael

[Jamie-SA]

Given that opening from @uscholdm ...

The idea that an address is a rdfs:subClassOf gist:Content seems wrong to me. And that is not just an off the cuff remark, I've been thinking about it since Dan posted his "aha" message (not on github) a few days ago.

I've read the several threads this has been discussed in and I keep coming back to this. The capturing of the address, the written manifestation of an address is content (in RDF, the literal(s) that contain the address). But the idea of an address is something different, it is a destination where something physical or electronic can be delivered. That idea/concept, the class itself, I do not think is content.

I do not know where in gist I would put it. I think an address is part Artifact (or maybe not... we deal with human addresses which are artifacts, but even without humans the concept would still be valid), part Commitment (follow the routing guidelines and you should be able to find the location of something should be deliverable), part Goal (we create addresses in the hope of being able to locate or deliver something), part Place (except that gist:Place is too narrowly defined to be a specific geographic physical feature and excludes virtual places [how is that going to work in the metaverse?]).

Also, I think the use of the words physical and virtual when describing addresses might be subtly incorrect. The "physical" means that something physical can be delivered to the address, but the destination represented by the "physical" address might not be a specific physical spot that can be identified by GPS coordinates and never moves. The use of the word "virtual" I think has been used to represent an electronic destination. The address itself is not physical or virtual, but specifies what types of things can be delivered/received.

[justin2004]

I think this might mean we should make gist:isAbout's documentation slightly more general or slightly more specific. As it is currently it looks like it is somewhere between dcterms:subject and ^dcterms:isReferencedBy.

dcterms doesn't express this but I do think "being the subject of something" is a more specific kind of "being referenced by something." Given that, another option is to add Dan's proposed gist:refersTo as a superproperty (and an object property) of gist:isAbout. That would give Gist near equivalents to ^dcterms:isReferencedBy and dcterms:subject though.

[justin2004]

The capturing of the address, the written manifestation of an address is content (in RDF, the literal(s) that contain the address).

Yeah, @Jamie-SA , I think gist:Address as a subclass of gist:Artifact makes sense. But maybe it doesn't need to go further down the tree to gist:Content? Many things are trivially gist:Content (or could be if expressed somehow).

[uscholdm]

Jamies comments are very interesting. Addresses that correspond to physical places often do not correspond to what is a fixed area on the surface of the earth. A PO box is a good idea. The physical location of my wifes po box moved to a mile a way. The address, as content did not change. Dave's emphasis that an address always corresponding to a routing algorithm to get to 'somewhere' applies here. The address stayed the same, the routing algorithm may have been the same, but the inputs to the algorithm may have changed to pop out a new physical place.

ALso, many addresses inside companies go to a slot in a mail room which is never going to correspond to a GeoRegion, you;d need something more granular - and anyway, the mail room can move down the hall or to a different floor much like my wife's PO box.

So I'm leaning towards keeping address as content.

[uscholdm]

the use of the words physical and virtual when describing addresses... The address itself is not physical or virtual, but specifies what types of things can be delivered/received.

What I mean by a physical address is that the routing algorithm at any given moment will take you to a physical place on the earth - whether in a house, or a mailroom or a PO Box post office or most interestingly perhaps, a slot in a room on a shipp for a shipping address for a naval officer whose ship could be anywhere.

THE other addresses whether we call them virtual or electronic, I don't have a view, but what is definitely true is that the routing algorithm will not take a message to a physical place in any useful sense of 'physical place'.

[DanCarey404]

The physical location of my wife's po box moved to a mile a way. The address, as content did not change. Similarly, a house's address can be changed (road name, building number, even city can be changed), but the house remains fixed to the earth.

[DanCarey404]

Most of this discussion about the nature of Address should more appropriately be conducted under my #721 ticket.

[DanCarey404]

Circling back to @uscholdm's original comment... If we assume that Address remains a subclass of Content, what verb would you suggest we use to link a physical address to a geopoint and/or georegion?

[uscholdm]

what verb would you suggest we use to link a physical address to a geopoint and/or georegion?

'routesTo' is one possibility

[DanCarey404]

That works when you are tying an address to a very specific place. But what if I want to tie the address to the country georegion? In that case routesTo doesn't seem as appropriate, IMO. But having that property would make defining the Address class easier and more accurate. Hmm....

[justin2004]

what verb would you suggest we use to link a physical address to a geopoint and/or georegion?

oh, i think gist already has the obj prop needed (from the other direction): gist:hasAddress

[uscholdm]

Intersting, isAddressOf would be the natural name for that property. Most often it is a person or a business that has an address, sometiems a building, rarely a GeoRegion.

[DanCarey404]

@justin2004 "America hasAddress :4815TabardPl" doesn't work.
We need a way to say that an Address points to or indicates some Place. That Place can be as big as a country or as specific as a building. It is very natural in business data to want to link an address to its country, state, city (which have their own IRIs) because you want to query for the Addresses in that GeoRegion.

[justin2004]

@DanCarey404 I think I might do something like:

[ gist:hasAddress  :4815TabardPl ]  gist:isGeographicallyContainedIn :America .

Upgrading the bnode as necessary. What do you think?

[DanCarey404]

Nope, because the blank node could be a person, an org, a building that has the address. The domain and range on :isGeographicallyContainedIn are :Place. (Also, I am generally opposed to relying on blank nodes when transforming data.)

[justin2004]

How about:

:pep0 a gist:Person .
:pep0 gist:hasPhysicalLocation :loc0 .
:org0 a gist:Organization .
:org0 gist:hasPhysicalLocation :loc0 .
:bldg0 a gist:Building .
:bldg0 gist:hasPhysicalLocation :loc0 .
:loc0 gist:hasAddress :4815TabardPl ;
         gist:isGeographicallyContainedIn :America .

[DanCarey404]

While that works, it adds a level of indirection. I'd prefer to find a property name that does what the ticket is requesting. But perhaps this ticket should wait until we address the real nature of the Address class in ticket #721 .

[justin2004]

I feel like one of Gist's purposes is to prevent two arbitrary things from being directly connected. It feels ideal for some things to have some semantic distance between them.

Gist makes you say "thing X has a physical location - that location has an address - that location is contained within a place."

And the corresponding triple patterns:

?thing gist:hasPhysicalLocation ?loc .
?loc gist:hasAddress ?addy ;
       gist:isGeographicallyContainedIn* ?place .

(I know you know that too I just wanted to type it out to see how the indirection feels.)

I think I prefer that indirection. Without some indirection we'd have full mesh graphs!

[rjyounes]

I agree with @DanCarey404 - the address discussion should be moved to the other issue. To comment on the proposal of gist:refersTo, @DanCarey404 I think you mean an object property rather than a datatype property? I've take the liberty of changing the issue title.

I have just had a need to define an object property refersTo in a client ontology, and support the addition of this predicate to gist, without the domain specification. It's a good all-purpose predicate for which I can't find anything comparable in gist. Though it's an open question whether content referring to something and non-content referring to something are close enough in meaning to warrant one predicate rather than two.

[rjyounes]

@justin2004 gist:hasAddress does not address the case Dan is describing: he wants my home address to point to, say, the city, state, country in which it's located, but this is not the address of that place.

[justin2004]

@rjyounes , I meant that in Dan's example we can follow gist:hasAddress backwards.

e.g.

?addy ^gist:hasAddress/gist:isGeographicallyContainedIn* ?place

Also, @DanCarey404 , I didn't see gist:residesAt in the current version of Gist.

[uscholdm]

I have just had a need to define an object property refersTo in a client ontology, and support the addition of this predicate to gist, without the domain specification.

Semantically, refersTo is closely related to gist:identifies (inverse of identifiedBy) - perhaps a super-property?

[uscholdm]

?addy ^gist:hasAddress/gist:isGeographicallyContainedIn* ?place

Inverse of hasAddress has Address as its domain. That makes ?addy a gist:Address, which I don't think you mean.

[justin2004]

That is what Dan wanted in his example:

:_1617Humboldt a gist:Address .
:_RussianRiverWatershed a gist:GeoRegion .
:_Steven gist:residesAt :_1617Humboldt .
:_1617Humboldt gist:refersTo :_RussianRiverWatershed .

:_1617Humboldt is a gist:Address

[justin2004]

@DanCarey404 I did a little experiement with an OWL 2 RL reasoner.

I put Gist and this:

:refersTo owl:propertyChainAxiom  ( [ owl:inverseOf gist:hasAddress ] gist:isGeographicallyContainedIn  ) .

into the the Tbox and this:

:stevens_house gist:hasAddress :addy0 .
:stevens_house gist:isGeographicallyContainedIn :watershed0 .
:watershed0 gist:isGeographicallyContainedIn :franklin_county .
:franklin_county gist:isGeographicallyContainedIn :america .

into the Abox.

Then ran:

prefix : <http://example.com/>
select * where {
   ?s :refersTo ?o .
  }

which yields:

s	o
http://example\.com/addy0	http://example\.com/watershed0
http://example\.com/addy0	http://example\.com/franklin\_county
http://example\.com/addy0	http://example\.com/america

Which is a long way of me saying I think defining a :refersTo using Gist primitives in a sub-ontology might be the way to go.

[rjyounes]

residesAt does not exist in gist, it is in a proposal of modeling addresses proposed by Dave. He does not necessarily propose adding the predicate to gist, but may be just using it illustratively. PowerPoint attached. Addresses in gist - Read-Only.pptx

[rjyounes]

Semantically, refersTo is closely related to gist:identifies (inverse of identifiedBy) - perhaps a super-property?

@uscholdm In my use case it is not at all related to gist:identifies, and I don't see how it would be as a general case.

[uscholdm]

This is a bit of a hairball of intermingled issues. See also #471, #483, #594, #721, #1009. It will take some effort to read through them all and distill out the core into questions and proposals.

[uscholdm]

@DanCarey404

We need a way to say that an Address points to or indicates some Place. That Place can be as big as a country or as specific as a building. It is very natural in business data to want to link an address to its country, state, city (which have their own IRIs) because you want to query for the Addresses in that GeoRegion.

I think it would be better to point an address to the narrowest physical place that makes sense. The place where the routing algorithm takes you. From there, you can use geo containment to your heart's content. Having one predicate for directly linking an address to many regions of different sizes seems like a bad idea to me.