Re: Property "geographic identifier" in LOCN

Hi Raphael,

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.
>>
>
> But if the GNIS is just a 10 digits number, you need to mint a URI for
> this number and you need a URI policy for this. It seems to me that a GNIS
> may be a literal or may be a URI. Therefore, I would rather suggest to use
> a property that has no constraint on its range and could accept both (like
> many dce properties).


GNIS ids are just one case of identifiers, so I think I agree with you in
having an undefined range for this property.
Otherwise, we would have to introduce just-another-unique-identifier that
would then have some properties linking to a GNIS id for example, but after
all IK think it would be a bit superfluous.


>
>  We could follow the current practice and use the owl:sameAs for this
>> reason, but I think it is problematic in this case.
>>
>
> owl:sameAs can work only if we have two URIs since a literal cannot be the
> subject of a statement. However, I just show above that without a URI
> policy and someone responsible to mint URI for GNIS, we might only have
> literals to manage. Therefore, owl:sameAs is not appropriate for those
> cases. I believe you're arguing for having a specific geographic identifier
> property for which the range would be loose (URI or literal).


Sure. I was thinking about the scenario where a locn:geometry-identifier
would have been introduced by the locn vocabulary.

Cheers,
Kostis