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

On 2014-01-14 13:57, Sven Schade wrote:
>
> 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?
>
If that class exists, we can attach properties to it. Properties that 
already exist in the vocabulary, like geometry, address or name. From a 
consumers' perspective: If a thing is designated as being a spatial 
thing, one can expect that it might have certain characteristics, like 
an address, a geographical name,  a geometry. That is useful.

Regarding the new properties proposed by John: Let's assume a spatial 
feature like a city. It could have tens of different geometries. I think 
that in most cases a user agent will be interested in the centroid or 
MBR of the city (the feature), not of all the different geometries. 
Although I can also imagine that a user agent does want to get the 
centroid or MBR of a particular geometry. So I think the new properties 
could be properties of both spatial features and geometries.

> 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?
>

Because the extra class ties things that already exist in the vocabulary 
together. And because the ISO TC211 community has a different scope. It 
is not Linked Data, and the ISO 191xx standards are not that simple and 
adoptable.

It is interesting to see that vocabularies like GeoSPARQL and NeoGeo 
also saw a need to have a 'Feature' entity.

Regards,
Frans


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


-- 
--------------------------------------
*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 13:48:54 UTC