Re: Property "geographic identifier" in LOCN

Hi Kostis,

The problem with "geographic identifier" seems to be insuring that a URI not "out rank" another ns's URI for the same Feature (entity).  This would quite literally be a "land grab".  The web can do without more of those.

Might it be worthwhile to voluntarily limit LOCN to equivalent  "actual" (before "now") and "virtual" (after "now") URI policies ?  

http://www.w3.org/TR/owl-ref/#SymmetricProperty-def

<owl:SymmetricProperty rdf:ID="geographicIdentifierOf">
  <rdfs:domain rdf:resource="#Place"/>
  <rdfs:range  rdf:resource="#Place"/>
</owl:SymmetricProperty>  

Specifically, what is symmetric is the Lorenz curve[1] because Gibrat's rule of proportionate growth[2] unilaterally applies across the range (the proportional growth of the Eiffel Tower is 1/1 not 0/0 for example).  I first thought this was ludicrously pedantic, but then I read in [2]:

"In the study of the firms (business), the scholars do not agree that the foundation and the outcome of Gibrat's law are empirically correct."

Sounds like the "scholars" are assuming "authority" to me.  All URI's should be defined as anonymously owned currency, I think.  Linked Data will work better. 

--Gannon



--------------------------------------------
On Mon, 1/6/14, Kostis Kyzirakos <Kostis.Kyzirakos@cwi.nl> wrote:

 Subject: Re: Property "geographic identifier" in LOCN
 To: "Raphaël Troncy" <raphael.troncy@eurecom.fr>
 Cc: "Frans Knibbe | Geodan" <frans.knibbe@geodan.nl>, "LocAdd W3C CG Public Mailing list" <public-locadd@w3.org>
 Date: Monday, January 6, 2014, 11:45 AM
 
 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

Received on Monday, 6 January 2014 23:18:44 UTC