Re: Property "geographic identifier" in LOCN

On Fri, Jan 3, 2014 at 5:49 PM, Raphaël Troncy <raphael.troncy@eurecom.fr>wrote:

> From what you're saying, in the US, this GNIS ID is a literal. Is it
> always true?
>

The GNIS identifier is an (up to) ten digit number. However, there are many
other forms
of identifiers (e.g., guid are used in many datasets that I have seen), so
I think that the
safest choice would be to have a URI so that we could say a few thinks
about it afterwards,
e.g., by using different (small) vocabularies for each standard.

In the RDF world, this geographic object will have a URI as identifier.
> There is a need to have a property for which the value will be this
> geographic identifier so that other tools/datasets/processing
> chains/infrastructure in general can make use of it.
>

I agree. This is why I find the property  geographic identifier to be very
important in practice.


> In the current vocabulary locn vocabulary, the property rdfs:seeAlso is
> hijacked which is not a good practice IMHO. More precisely, the locn
> vocabulary provides a new rdfs:label to this property defined in another
> ns.
>
Are you arguing that the locn vocabulary should have its own geographical
> identifier property? How such a property would be defined? What constraints
> (if any) should be put on the range of this property?
>

No, indeed. For the RDF world, a URI will be used to uniquely identify a
feature. However, we need something to glue this URI to other identifiers
from the GIS world.
We could follow the current practice and use the owl:sameAs for this
reason, but I think it is problematic in this case. What would a owl:sameAs
link mean between two locations? That they represent the same location?
That they have the same spatial extent? I am not sure if this is
appropriate in this case. This is why I would not choose owl:sameAs links
for this. What do you mean when you say that the rdfs:seeAlso is hijacked?