Re: A proposal for two additional properties for LOCN

On 2014-09-08 4:00, Simon.Cox@csiro.au wrote:
>
> Yes, I would suggest
>
> locn:crs a owl:ObjectProperty ;
>
> rdfs:label "coordinate reference system used" ;
>
> rdfs:range locn:CRS .
>
> locn:CRS a owl:Class ;
>
> rdfs:label "coordinate reference system" .
>
> Then in data when you see
>
> my:Thing locn:crs <http://example.org/c> .
>
> a reasoner will tell you that the resource denoted 
> <http://example.org/c> is a member of the class denoted locn:CRS.
>
> The inference stands regardless of whether an RDF representation can 
> be obtained or not (in the open-world we can assume/hope one is 
> available somewhere, even if we don't know where, yet!).
>

Hello Simon, all,

I really like this approach. It is very similar to the way geometry is 
handled in LOCN now: There is a class locn:Geometry that can be used for 
any definition of geometry and there is a property locn:geometry to make 
an association with an instance of locn:Geometry.

If there are no objections I would like to put this in the proposal. But 
wouldn't it be better to use rdfs:Class instead of owl:Class and 
rdf:Property instead of owl:ObjectProperty? I understand that it is good 
practice to stick with RDF/RDFS if possible and only use OWL if there is 
no alternative in the simpler schemas.

Regards,
Frans


> Simon
>
> *From:*Frans Knibbe | Geodan [mailto:frans.knibbe@geodan.nl]
> *Sent:* Friday, 5 September 2014 8:10 PM
> *To:* Cox, Simon (L&W, Highett); public-locadd@w3.org
> *Subject:* Re: A proposal for two additional properties for LOCN
>
>
>
> On 2014-09-03 2:22, Simon.Cox@csiro.au <mailto: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 <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>
------------------------------------------------------------------------