W3C home > Mailing lists > Public > public-locadd@w3.org > January 2014

Re: Sub-properties for locn:geometry? (was: RE: ISA Core Location Vocabulary)

From: Oscar Corcho <ocorcho@fi.upm.es>
Date: Tue, 14 Jan 2014 16:22:32 +0100
To: Sven Schade <sven.schade@jrc.ec.europa.eu>, <Simon.Cox@csiro.au>, <frans.knibbe@geodan.nl>, <public-locadd@w3.org>
Message-ID: <CEFB140A.9311E%ocorcho@fi.upm.es>
In my opinion, the distinction between features and geometries is very
relevant. 

Our use case (very simple indeed):

One of the datasets that we handle at our APIs in Localidata is related to
business units in cities (shops, theaters, etc., that is, places in
general). 
* From the perspective of a general user, a shop can be easily represented
with a lat-long, or a set of lat-longs for the different entries if in
different streets.
* From the perspective of the city managers, a shop is also related to the
actual unit where it is, and hence a polygon is needed (the ones usually
used by cadastral offices).

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:  Sven Schade <sven.schade@jrc.ec.europa.eu>
Fecha:  martes, 14 de enero de 2014 13:57
Para:  <Simon.Cox@csiro.au>, <frans.knibbe@geodan.nl>,
<public-locadd@w3.org>
Asunto:  RE: Sub-properties for locn:geometry? (was: RE: ISA Core Location
Vocabulary)
Nuevo envío de:  <public-locadd@w3.org>
Fecha de nuevo envío:  Tue, 14 Jan 2014 12:57:50 +0000

Absolutely. So we should agree if we need such an additional element, which
would make the overall vocabulary more complex, i.e. less simple and
adoptable.
 
We might try to answer the following three (subsequent) questions:
1)      What would be a use case for which we would need a feature (or
similar) class?

2)      Why could this use case not be realized with the more light-weight
model that was initially suggested by John?

3)      Would such a use case appear outside the ISO TC211 community, which
already have a well-established model, the GFM?

 
Sven
 

From: Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au]
Sent: Tuesday, January 14, 2014 12:58 PM
To: frans.knibbe@geodan.nl; public-locadd@w3.org
Subject: RE: Sub-properties for locn:geometry? (was: RE: ISA Core Location
Vocabulary)
 
FWIW a revision of ISO 19109 is in the works (it reached DIS stage last
year). 
It is the standard that defines the ŒGeneral Feature Model¹
-          i.e. that identifiable Objects in geographic information are
known as ŒFeatures¹ and that these have various kinds of Œproperty¹ ­ all
rather old hat to both oo and DL folk, but usefully formalized for the geo
community. 

An important clarification in the rule for features is
 
³Features shall not be modelled as specializations of GM_Object (ISO
19107:2003) or TM_Object (ISO 19108:2002).²
 
Similarly, in GeoSPARQL
geo:Feature
      a       owl:Class ;
      rdfs:subClassOf geo:SpatialObject ;
      dc:description """
      This class represents the top-level feature type. This class is
      equivalent to GFI_Feature defined in ISO 19156:2011, and it is
      superclass of all feature types.
    """@en ;
      owl:disjointWith geo:Geometry .
 
So in that community there is a clear and consistent intention to
distinguish between geometries and features.
 
Simon
 

From: Frans Knibbe | Geodan [mailto:frans.knibbe@geodan.nl]
Sent: Tuesday, 14 January 2014 9:56 PM
To: public-locadd@w3.org
Subject: Re: Sub-properties for locn:geometry? (was: RE: ISA Core Location
Vocabulary)
 

On 2014-01-14 11:19, Sven Schade wrote:
> Geometries are points, lines, polygons, etc. For me, this should be separated
> from the role they play in representing spatial aspects (centroid, MBR,
> Footprint, etc.) of a Œreal world¹ object.
>  
> Taking an example from the source of the core location vocabulary [1], a
> ³Person² might be related to a ³Location² by the properties ³countyOfBirth²,
> ³countyOfDeath², etc. A ³Location² might then refer - via the ³geometry²
> property - to a ³Geometry² class, which might be a point, line, polygon, etc.
> The ³Geometry² can have different relations to the ³Location², e.g. a point
> might represent the centroid of a country, a polygon might approximate the
> boundary.
>  
> For this reason, we should look for sub-properties of ³locn:geometry² (as
> initially proposed by John), but not for sub-classes of ³locn:Geometry².

And what about the alternative of defining them as properties of a
geographical feature (or spatial object or spatial thing or whatever)? That
concept has not (yet) been defined in the LOCN vocabulary, but it is present
in other models for geographical data. We could consider introducing it in
the vocabulary. Interestingly enough, the concept is mentioned in the
definition of locn:geographicName: "A geographic name is a proper noun
applied to a spatial object".


 
Best regards,
Sven
 
[1] https://joinup.ec.europa.eu/site/core_location/rdfs.html
 
 

From: Frans Knibbe | Geodan [mailto:frans.knibbe@geodan.nl]
Sent: Friday, January 10, 2014 2:24 PM
To: public-locadd@w3.org
Subject: Re: Sub-properties for locn:geometry? (was: RE: ISA Core Location
Vocabulary)
 

On 2014-01-10 13:00, John Goodwin wrote:
>  
> Frans Knibbe wrote:
>  
> As all the subproperties are geometries themselves, why not define them as
> subclasses?
> 
> 
> 
> The simple feature ontology does subclass geometry to polygons, points etc.
> Are you suggesting having new classes for things like Œcentroid¹ (e.g.
> subclass of sf:Point) etc?
I don't really know... I was thinking that geometries like centroid or MBR
are specialized geometries. They have additional constraints, like a
centroid always being a point and a MBR always being a rectangle. So it that
sense they are much like  simple feature geometry types like point or
polygon or multiline. But they also have other meanings, like the MBR
enclosing all geometry and the centroid being a 'center of mass'. So if
there were RDF definitions for something like the Simple Features
specification I guess it would make sense to view these new classes as
subclasses of existing types. But in many current specifications, the
geometry type is encoded together with the coordinates, NeoGeo being an
exception. It can be confusing.

Given the idea that a geographical feature like a municipality can have many
different geometries (for instance with different levels of detail), I think
the idea is to associate things like centroid or MBR with the feature, not
with a geometry of a feature. Will that work if something like a centroid is
a property of a geometry?

Perhaps the LOCN vocabulary should include the notion of a geographical
feature (something that can be modelled to have geometry), so specialised
geometries like MBR can be defined as properties of that class?

Regards,
Frans



 

-- 
--------------------------------------
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>
--------------------------------------
Received on Tuesday, 14 January 2014 15:23:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:19:15 UTC