Re: A proposal for two additional properties for LOCN

On 2014-09-03 2:22, Simon.Cox@csiro.au wrote:
>
> ØAs for using xsd:anyURI, I am happy with it (I would probably prefer 
> having a class CRS with instances for it
>
> +1
>
> Yes -- I do not like to see anyURI as the range for anything, except 
> for a property whose job is to assign an identifier.
>
> If you want to defer specifying a range, then make it an 
> owl:ObjectProperty .
>

Hello Simon, all,

My idea was to have something that encourages using a URI that resolves 
to data about the CRS, like the URIs IGN France is providing, but does 
not exclude URIs that do not resolve to RDF data, like the OGC URIs at 
the moment. So in that case it only assigns a globally unique 
identifier, but it is an identifier that does not need to be changed 
should it resolve to RDF data some time in the future. If the URI is a 
HTTP URI, that is.  Does that make sense?

I just did some reading on the subject and think I now understand that 
the problem with xsd:anyURI is that it is a string and not a resource. 
And a string can not magically become a resource. Bummer.

For data processing it would best if the domain is a CRS class with all 
the necessary properties. But that wouldn't that mean that we have to 
pick an authoritative definition of a CRS class? I don't think LOCADD is 
the right place to add a CRS class definition, that goes beyond the 
concept of a simple core vocabulary. So if a class is used for the range 
it would be class that is defined in another vocabulary. Is the 
geospatial world ready for choosing an authoritative CRS class definition?

How about defining a CRS class in LOCN without any properties? Then we 
could use that class for the range of locn:crs . Organisations like the 
OGC or IGN France could flesh out such a class, creating subclasses of 
the locn:CRS class. How is that?

Regards,
Frans

> *From:*Oscar Corcho [mailto:ocorcho@fi.upm.es]
> *Sent:* Wednesday, 3 September 2014 4:34 AM
> *To:* Frans Knibbe | Geodan; LocAdd W3C CG Public Mailing list
> *Subject:* Re: A proposal for two additional properties for LOCN
>
> Dear Frans,
>
> For the use cases that I have in mind, the first one covers well the 
> needs that I had. I would probably use a shorter qName, such as 
> locn:crs, which should be in general well understood.
>
> With respect to the domain, I cannot understand well why you want to 
> associated it to a Dataset, and I would probably leave it associated 
> to locn:Geometry, or even leave the domain unspecified.
>
> As for using xsd:anyURI, I am happy with it (I would probably prefer 
> having a class CRS with instances for it, as I think that was 
> suggested by Ghislain Atemezing some time ago, but having the anyURI 
> datatype seems sufficient to me at this point.
>
> Oscar
>
> -- 
>
> Oscar Corcho
>
> Ontology Engineering Group (OEG)
>
> Departamento de Inteligencia Artificial
>
> Facultad de Informática
>
> Campus de Montegancedo s/n
>
> Boadilla del Monte-28660 Madrid, España
>
> Tel. (+34) 91 336 66 05
>
> Fax (+34) 91 352 48 19
>
> *De: *Frans Knibbe | Geodan <frans.knibbe@geodan.nl 
> <mailto:frans.knibbe@geodan.nl>>
> *Fecha: *lunes, 1 de septiembre de 2014 14:49
> *Para: *LocAdd W3C CG Public Mailing list <public-locadd@w3.org 
> <mailto:public-locadd@w3.org>>
> *Asunto: *A proposal for two additional properties for LOCN
> *Nuevo envío de: *<public-locadd@w3.org <mailto:public-locadd@w3.org>>
> *Fecha de nuevo envío: *Mon, 01 Sep 2014 12:50:48 +0000
>
> Hello all,
>
> I have made a wiki page for a provisional proposal for the addition of 
> two new properties to the Location Core Vocabulary 
> <https://www.w3.org/community/locadd/wiki/Proposal_for_extension_of_LOCN_with_properties_for_Coordinate_Reference_System_and_Level_of_Detail>: 
> CRS and spatial resolution. I would welcome your thoughts and comments.
>
> The proposal is based on earlier discussions on this list. I am not 
> certain about any of it, but I think starting with certain definitions 
> can help in eventually getting something that is good to work with.
>
> Some questions that I can come up with are:
>
>  1. Are the semantics of the two properties really absent from the
>     semantic web at the moment?
>  2. Is the Location Core Vocabulary an appropriate place to add them?
>  3. Is the proposed way of modelling the two properties right? Could
>     conflicts with certain use cases occur?
>
> More detailed questions are on the wiki page.
>
> Regards,
> Frans
>
> ------------------------------------------------------------------------
>
> Frans Knibbe
> Geodan
> President Kennedylaan 1
> 1079 MB Amsterdam (NL)
>
> T +31 (0)20 - 5711 347
> E frans.knibbe@geodan.nl <mailto:frans.knibbe@geodan.nl>
> www.geodan.nl <http://www.geodan.nl> | disclaimer 
> <http://www.geodan.nl/disclaimer>
>
> ------------------------------------------------------------------------


------------------------------------------------------------------------
Frans Knibbe
Geodan
President Kennedylaan 1
1079 MB Amsterdam (NL)

T +31 (0)20 - 5711 347
E frans.knibbe@geodan.nl
www.geodan.nl <http://www.geodan.nl> | disclaimer 
<http://www.geodan.nl/disclaimer>
------------------------------------------------------------------------