Re: Spatial identification of subjects

Doing some things of my own in this space at the moment, I have to strongly agree with Kal and Aki here.  What you find in practice is that many "standard" geolocations exist for places you want to talk about, so you either a) pick one and use that as your gospel version, or b) do a and track all of them so that you can continue to interoperate with other sources of "the truth".

I don't see how this particular thing fits in with semantic identity.  For most domains, a geolocation is a property of a subject of discourse, so I also think it should be treated as such.

Cheers,

ast

On 4 Oct 2010, at 9:56 AM, Khalil Ahmed wrote:

> I would ask if it is really necessary for geo-location to be encoded
> as a subject identifier rather than simply recorded as a topic
> property (such as an occurrence).
> 
> If you accept that merging of geo-location identifiers is problematic
> (requiring some fuzzy processing), but require nevertheless that you
> should be able to do things like the findNearBy functionality of
> Geonames, then it seems to me that an occurrence with a well-defined
> type is the way to go. It would be trivial to define your own merge
> semantics, but I don't think you should be relying on the standard
> subject identifier merge semantics to work for you unless you can be
> absolutely clear about the subject you are identifying. A 2D
> geo-location actually identifies a region of the planet's surface and
> so can really only be used for that purpose. I can absolutely
> empathise with the requirement for some way to identify the place you
> want to talk about, but it seems to me that equating, London, Leipzig
> or Lapland to a single geo-coordinate is confusing at the very least.
> 
> Geo-location-based subject identifiers  (whether temporally qualified
> or not) seem more like a case of having a hammer and wanting
> everything to be a nail :-)
> 
> Cheers
> 
> Kal
> 
> On Mon, Oct 4, 2010 at 9:42 AM, Aki Kivela <[email protected]> wrote:
>> 
>> Hello Richard and all
>> 
>> I recall thinking similar thoughts while listening Sven's talk at TMRA. Geo
>> coordinates are just too fuzzy to be used as subject identifiers. It is just
>> too probable two people addressing same geo location, say Leipzig, would
>> have slightly different subjects due to different coordinates.
>> 
>> And, one should not forget, it is a geological fact that at least some parts
>> of the earth are constantly moving i.e. their geo coordinates are changing
>> over time. For example, earth ground is rising upward here in Finland. And I
>> recall reading California is moving ~10 centimeters per year. These are
>> small numbers but the effect is same. As time passes, subject identifiers
>> based on geo coordinates are gradually eroded.
>> 
>> But, I must agree with Sven that sometimes it might be useful to really use
>> temporal subject identifiers based on geo coordinates. And, one could later
>> on solve a better subject identifier for the geo topic using a service like
>> Subj3ct or Mappify. However, the algorithm mapping coordinates to subject
>> identifiers should be error tolerant. Actually, GeoNames seems to already
>> have such a service: findNearby [1].
>> 
>> Kind Regards,
>> Aki Kivelä
>> Wandora Team
>> 
>> 
>> [1] http://www.geonames.org/export/web-services.html#findNearby
>> 
>> 
>>> Hi,
>>> 
>>> First of all, thanks to the organisers of TMRA for an absorbing
>>> conference, and a chance to re-acquaint myself with the Topic Maps scene.
>>> 
>>> One talk which got me thinking was Sven Krosse on identity for places.
>>> I'm afraid I don't agree with this approach, and wonder what others think.
>>> 
>>> As it happens, I just went across to Subj3ct.com and found that there is
>>> a steady stream of these "geo:" identifiers arriving there. A random
>>> example is:
>>> 
>>> geo:51.7,20.5333333;crs=wgs84
>>> 
>>> This is equivalent to the Geonames concept 774834:
>>> 
>>> http://sws.geonames.org/774834/about.rdf
>>> 
>>> The first problem I have with these identifiers is that they are not
>>> dereferenceable. You can clearly see this if you click on the link
>>> helpfully provided on the Subj3ct page for this identifier. ("Firefox
>>> doesn't know how to open this address, because the protocol (geo) isn't
>>> associated with any program.") Therefore they have no value as Linked
>>> Data identifiers.
>>> 
>>> The second problem is that it is far from clear to me how users are
>>> meant to find out the exact coordinates of the centroid of a place, and
>>> use those to generate the "right" identifier for that place. Bujaly is a
>>> small place, but even there I see that there are already two distinct
>>> "geo" identifiers associated with it, even before any users come along
>>> and try to guess what the "right" coordinates might be. How much harder
>>> would it be for a place the size of London?
>>> 
>>> The third problem is one of semantic overloading. A WGS84 coordinate is
>>> just that, and should in the Linked Data scheme of things have its own
>>> identity. Dropping onto that identity the additional load of
>>> representing a populated place simply confuses the issue. Also, there
>>> are different types of "place": popular usage; administrative areas;
>>> political constituency boundaries; etc. What happens when two such
>>> entities happen to have the same boundaries and therefore the same
>>> centroid?
>>> 
>>> It is clearly tempting to look for a "magic bullet hash function" which
>>> will generate shared unique identifiers, but I don't think that this is
>>> the right thing to do. In general, I would go for a strategy where your
>>> identifiers are deliberately lacking in significance, like Geonames'
>>> numerical identities, and you use the properties of a published subject
>>> to determine equivalence.
>>> 
>>> In this case, the original Geonames RDF gives you the place name and the
>>> WGS84 coordinates. It would be a simple matter to match on the name, and
>>> then check that the coordinates are "sufficiently close" to your own
>>> coordinates for that place, to be sure that the Geonames identifier
>>> refers to the same place. Another strategy, which would be more relevant
>>> for the sort of museum data I am familiar with, would be to use the
>>> containment relationships between this place and the larger geopolitical
>>> units it falls within.
>>> 
>>> Clearly, deriving and sharing unique persistent identifiers for
>>> subjects/concepts is a major challenge. I think this challenge is best
>>> met by publishing as many (machine-processible) properties with a
>>> published subject identifier as you can, so that others can deduce
>>> (possibly algorithmically) whether the entity they are considering
>>> matches the one you have published. We may, for example, end up with
>>> "virtual merges" [1] which have a numerical degree of confidence
>>> associated with them.
>>> 
>>> Richard
>>> 
>>> [1] Jack Park, Topic Map scenarios for Knowledge Federation, TMRA 2010
>>> 
>> _______________________________________________
>> topicmapmail mailing list
>> topicmapmail-Zo64W7twoUFWk0Htik3J/[email protected]
>> http://www.infoloom.com/mailman/listinfo/topicmapmail
>> 
> 
> 
> 
> -- 
> Kal Ahmed
> Director, Networked Planet Limited
> e: [email protected]
> w: www.networkedplanet.com
> t: +44 1865 811131
> _______________________________________________
> topicmapmail mailing list
> topicmapmail-Zo64W7twoUFWk0Htik3J/[email protected]
> http://www.infoloom.com/mailman/listinfo/topicmapmail

--
Andrew S. Townley <[email protected]>
http://atownley.org