Re: GeoSpatial vocabularies

Hello Thomas,

A nice find, that OGC discussion paper. Like INSPIRE, it firmly embraces 
the OGC family of standards (a.k.a. ISO-191xx). In my mind, this grossly 
overcomplicates matters. If there is to be some kind of fusion of the 
Way of Linked Data and the Way of ISO-191xx, I think it makes more sense 
to start with the principles of Linked Data instead of the other way 
around. The fact that we now have GeoSPARQL as an OGC standard could 
help a lot there. For the people or organizations that want the use 
official OGC standards it legitimates publishing data using Linked Data 
principles.

Take metadata for example. Why not just use VoiD for describing spatial 
datasets? For geographic data, we just need some extra terms to cover 
some vital properties of spatial datasets (like spatial extent and 
spatial resolution). Wouldn't that be much nicer than starting from 
ISO-19115?

A general problem with INSPIRE is that there is no nice and clean 
separation between the logical or conceptual models and the implementing 
rules or serializations of data. I hope it will be possible to set up 
INSPIRE-based data services using Linked Data principles and GeoSPARQL, 
and ignoring ISO-191xx as much as possible. In fact, I am working on 
such an experiment now. I believe that such data services will be much 
better at achieving the goals of INSPIRE in the end.

By the way, I am in the process of joining the Community Group (waiting 
for a manager to return from vacation).

Greetings,
Frans

On 8-8-2012 16:12, Thomas Bandholtz wrote:
> Hi Frans,
>
> you may be right, but we have a European Legislation named INSPIRE [1],
> and this prescribes OGC standards - among others CSW.
> However, RDF serialisation may be supported if someone writes what they
> call "implementing rules".
>
> I just came across an "OWL Application Profile of CSW" OGC discussion
> paper from 2009 submitted by a) Allworlds Geothinking
> b) University of Nottingham c) EDINA, University of Edinburgh. This may
> help as a start.
>
> Best,
> Thomas
>
> [1] http://inspire.jrc.ec.europa.eu/
>
> Am 08.08.2012 14:40, schrieb Frans Knibbe | Geodan:
>> Hello Thomas,
>>
>> Why do you think an RDF version of OGC Catalog Services is needed?
>> Don't the regular ways of describing datasets suffice?
>>
>> One reason I can think of is that we desperately need some way of
>> describing the spatial resolution (level of detail, level of
>> generalization) for datasets. I did suggest this to the GeoSPARQL
>> working group, but the idea was rejected. But perhaps the concept of
>> resolution of a dataset (or a single data resource) is not limited to
>> geospatial data. Other data about real world objects could be captured
>> or modelled at different levels of detail too. I really wonder if
>> there already is something out there that could be used to indicate
>> the resolution of spatial data.
>>
>> Regards,
>> Frans
>>
>>
>> On 8-8-2012 12:36, Thomas Bandholtz wrote:
>>> Phil,
>>>
>>> very good idea.
>>> Is anybody aware of some RDF for OGC Catalog Services?
>>> If not I will tinker a draft quite soon.
>>>
>>> Best regards
>>> Thomas
>>>
>>>
>>> Am 06.08.2012 14:46, schrieb Phil Archer:
>>>> Having been involved with a number of conversations recently, and
>>>> being aware of many more, I am proposing a new Community Group around
>>>> vocabularies for describing locations.
>>>>
>>>> See http://www.w3.org/community/groups/proposed/#locadd
>>>>
>>>> Background
>>>> ==========
>>>> This is hardly a new idea and the last thing I want to do is to fall
>>>> into the XKCD trap [1]. Nevertheless, we have different organisations
>>>> having similar but separate conversations at the moment, mostly born
>>>> of different use cases and perspectives. This is normal but I think
>>>> some sort of coordination could be beneficial.
>>>>
>>>> GeoSPARQL
>>>> =========
>>>> The OGC has completed work on GeoSPARQL [2]. This is favoured by the
>>>> likes of (UK mapping agency) Ordnance Survey and has been produced
>>>> primarily by geospatial experts with an interest in linked data.
>>>>
>>>> NeoGeo
>>>> ======
>>>> A community effort has produced NeoGeo [3]. This is favoured by the
>>>> likes of (French mapping agency) IGN and has been produced primarily
>>>> by linked data experts with an interest in geospatial data.
>>>>
>>>> The primary difference between GeoSPARQL and NeoGeo is in the way they
>>>> handle point, line and polygon literals. Both enjoy significant
>>>> support and implementation experience.
>>>>
>>>>
>>>> INSPIRE
>>>> =======
>>>> Is a European Commission Directive that legally obliges the Member
>>>> States of the European Union to publish environmental and geospatial
>>>> data using a common set of standards which are under various stages of
>>>> development [4].
>>>>
>>>>
>>>> ISA Programme Location Core Vocabulary
>>>> ======================================
>>>> Produced by a working group chaired by the team responsible for the
>>>> development of INSPIRE under the auspices of a different part of the
>>>> European Commission, this very lightweight vocabulary includes
>>>> properties and classes for describing locations and for recording
>>>> addresses in a manner conformant with INSPIRE - a feature not shared
>>>> by vCARD for example. Now a work item of the W3C Government Linked
>>>> Data WG [5], the vocabulary needs further community review and
>>>> refinement [6].
>>>>
>>>>
>>>> schema.org
>>>> ==========
>>>> Includes basic classes and properties for locations including:
>>>> - addresses (a clone of vCard) http://schema.org/PostalAddress
>>>> - lat/long (a clone of WGS84) http://schema.org/GeoCoordinates
>>>> - geoShape (including boc, circle, line & polygon)
>>>> http://schema.org/GeoShape
>>>>
>>>> It inherits things like name, URL and description from
>>>> schema.org/Thing which are at least analogous to things like
>>>> Geographic Names and Geographic Identifiers.
>>>>
>>>> schema.org includes containedIn but not, AFAICT, borders etc. The
>>>> schema.org location properties seem closely linked with event
>>>> vocabulary. Classes include Mountain, Body of Water, Continent etc.
>>>>
>>>> The current list of proposed extensions to schema.org [7] does not
>>>> include anything in this space and there is no (visibly active)
>>>> discussion associated with schema.org and location.
>>>>
>>>>
>>>> W3C Point of Interest
>>>> =====================
>>>> I'm sorry to say that the Points of Interest WG [8] seems to have hit
>>>> the buffers so that the March 2012 draft [9] looks like being as far
>>>> as it gets. This just at a time when more and more data is being
>>>> published, a lot of it related to locations and, well, points of
>>>> interest. The ideas behind the POI WG remain as important as ever but
>>>> it seems that a new focus is necessary if that work is to be leveraged
>>>> effectively.
>>>>
>>>>
>>>> Standards bodies
>>>> ================
>>>> OGC and W3C are both willing to help if required but what actually
>>>> *is* required? That's what the proposed community group is to find
>>>> out. When we know that, we can look at where any work should be done.
>>>> Like any membership organisation, both W3C and OGC put the wishes of
>>>> their members first. Both bodies are very willing to work together.
>>>>
>>>>
>>>> Possible outcomes
>>>> =================
>>>> One possible outcome is a standard that is backwards compatible with
>>>> GeoSPARQL and NeoGeo and that combines aspects of both. The danger
>>>> there is that this would lead to an over-complex standard that could
>>>> never be fully implemented - which is about as big a pointless waste
>>>> of time as can be imagined. However, the two are close and common
>>>> ground shouldn't be hard to find.
>>>>
>>>> At the other extreme is that everyone carries on in in their own way
>>>> and, well, people can pick and choose. This seems less than ideal to
>>>> me. If interoperability between data sets is important then we need to
>>>> make some effort to coordinate.
>>>>
>>>> The gaps seem to be around linked-data friendly INSPIRE standards,
>>>> particularly wrt addresses, and in handling geometry literals that can
>>>> be huge (no one is talking about yet another way to define points
>>>> lines and polygons btw!).
>>>>
>>>> What I hope the proposed group could achieve is:
>>>>
>>>> - consensus on the use cases/gaps that need be filled;
>>>> - at least a rough solution that takes full account of the existing
>>>> work highlighted here.
>>>>
>>>> If that can be done, the GLD WG's charter would allow it to take this
>>>> through the W3C Recommendations Track, assuming the continued support
>>>> and interest of the community. The WG itself does not have the
>>>> resources and geospatial expertise to see this through on its own.
>>>>
>>>> If this interests you, do please join the Community Group at
>>>> http://www.w3.org/community/groups/proposed/#locadd and post your
>>>> ideas.
>>>>
>>>> Thank you
>>>>
>>>> Phil.
>>>>
>>>>
>>>>
>>>> [1] http://xkcd.com/927/
>>>> [2] http://www.opengeospatial.org/standards/geosparql
>>>> [3] http://geovocab.org/doc/neogeo/
>>>> [4] http://inspire.ec.europa.eu/index.cfm/pageid/2
>>>> [5] http://www.w3.org/2011/gld/
>>>> [6] http://philarcher.org/isa/locn-v1.00.html although officially I
>>>> should point you to http://joinup.ec.europa.eu/asset/core_location/home
>>>> [7] http://www.w3.org/wiki/WebSchemas/SchemaDotOrgProposals
>>>> [8] http://www.w3.org/2010/POI/
>>>> [9] http://www.w3.org/2010/POI/documents/Core/core-20111216.html
>>>>
>>>>
>>
>>
>

Received on Tuesday, 14 August 2012 12:09:16 UTC