Re: Spatial identification of subjects
Aki Kivela <[email protected]>
| Newsgroups | gmane.text.xml.xtm.general |
|---|---|
| Message-ID | <[email protected]> |
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
>