RE: A proposal for two additional properties for LOCN from Simon.Cox@csiro.au on 2014-09-08 (public-locadd@w3.org from September 2014)

From: <Simon.Cox@csiro.au>
Date: Mon, 8 Sep 2014 09:28:08 +0000
To: <public-locadd@w3.org>
Message-ID: <2A7346E8D9F62D4CA8D78387173A054A5FFFBAB4@exmbx04-cdc.nexus.csiro.au>
Note: I understand how to use owl:Restriction to apply restrictions to outbound properties, but not how to restrict inbound, if that is what you are referring to.

In this case I also think that would be missing the point: it is actually important to state that the value of a locn:crs property should be a CRS definition.
OTOH I'm not sure that you would want to restrict where individual CRSs could be used.

Simon

From: Cox, Simon (L&W, Highett)
Sent: Monday, 8 September 2014 1:48 PM
To: 'janowicz@ucsb.edu'; public-locadd@w3.org
Subject: RE: A proposal for two additional properties for LOCN


Ø  guarded restrictions to scope crs locally (in the CRS class) instead of a global restriction

What's a 'guarded restriction'?
Google has pointed me at some stuff from early in OWL discussions, but nothing very recent.
What does it look like in OWL2? (preferably using Turtle)

Simon

From: Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
Sent: Monday, 8 September 2014 1:09 PM
To: public-locadd@w3.org<mailto:public-locadd@w3.org>
Subject: Re: A proposal for two additional properties for LOCN

Hi,

I would propose to use guarded restrictions to scope crs locally (in the CRS class) instead of a global restriction. If we leave CRS (more or less) undefined, we do not gain anything by the global inference anyway, but I will not argue about it if all of you prefer to have global domain and range restrictions on the roles.

Best,
Krzysztof


On 09/07/2014 07:00 PM, Simon.Cox@csiro.au<mailto: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><http://example.org/c> .

a reasoner will tell you that the resource denoted <http://example.org/c><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!).

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<mailto: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>
________________________________


--

Krzysztof Janowicz



Geography Department, University of California, Santa Barbara

4830 Ellison Hall, Santa Barbara, CA 93106-4060



Email: jano@geog.ucsb.edu<mailto:jano@geog.ucsb.edu>

Webpage: http://geog.ucsb.edu/~jano/

Semantic Web Journal: http://www.semantic-web-journal.net
Received on Monday, 8 September 2014 09:28:50 UTC