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

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

From: Sven Schade <sven.schade@jrc.ec.europa.eu>
Date: Tue, 14 Jan 2014 13:57:07 +0100
To: Simon.Cox@csiro.au, frans.knibbe@geodan.nl, public-locadd@w3.org
Message-id: <014101cf1128$21bc8240$653586c0$@jrc.ec.europa.eu>
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 <mailto: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 <mailto:frans.knibbe@geodan.nl>  
www.geodan.nl <http://www.geodan.nl>  | disclaimer <http://www.geodan.nl/disclaimer> 
--------------------------------------
Received on Tuesday, 14 January 2014 12:57:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:54:28 UTC