- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Sun, 7 Sep 2014 20:09:20 -0700
- To: <public-locadd@w3.org>
- Message-ID: <540D1DE0.1000305@ucsb.edu>
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 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!). > > 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> > > ------------------------------------------------------------------------ -- Krzysztof Janowicz Geography Department, University of California, Santa Barbara 4830 Ellison Hall, Santa Barbara, CA 93106-4060 Email: 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 03:09:56 UTC