Re: Schema.org extension for spatial data

Thanks, Dan.

Below is a response from Lieke Verhelst on your email. I am working with Lieke in the Geonovum testbed and forward her email as I am a member of the SDW working group.

I hope it clarifies some of your questions. We will also add some examples this week or next.

Thanks and best regards,
Clemens


—
Hi Dan,
 
First of all thanks for your thoughts and comments. It helps us to better understand the search engines’ point of view. 
 
Your assumption that “the idea is roughly to think through how a schema.org could/should handle these issues, rather than on bugfixes to our current (perhaps idiosyncratic) approach” is correct.
 
In the research our goal was to make *existing* (this is important) spatial data findable in the search engines. Ideally we would like to find this data via spatial questions such as: 
“give me all buildings located in Valkenswaard” 
“give me all schools located in Valkenswaard” 
 
Spatial data usually do not have many attributes apart from the spatial ones. As a consequence questions that have a spatial component (like “located in”) are evaluated via calculations on coordinates. For this to work a spatial data engine is required. We were referencing to GeoSparql when we wrote  “there are vocabularies that better support (..spatial analyses..) ". 

The sentence “search engines currently do not seem to be equipped with spatial indexes” is based on what we experience using a search engine that works with a search bar. (Obviously the Maps applications are an exception to the rule, and these applications are already widely used to publish spatial data, so out of scope for our research.) When a spatial question is entered, like give me all x located in y the UI can indeed show things on a map. But we assume that this is caused by attribute values such as schema:PostalAddress and not by making calculations on coordinates. So this mechanism will not work on our research data because this does not contain addresses, only coordinates. 
 
Our research has been successful so far that we now are able to make existing geospatial data on the record level findable via the search bar ( example: "site:ldproxy.net/bag/ Appingedam" and: "site:opendatacat.net water" ) . 

Our sgeo extension proposal was merely based on making it easier to mark up the data than to make a particular use case happen. Having that said it would be ideal if one day a person could ask "Give me all schema.org/Thing's in a radius of 100 meter around me… "or: "all schema.org/Thing's where I am inside of" . Obviously this is going to look like some kind of union of Maps & Search Bar.



> Am 19.02.2016 um 15:02 schrieb Dan Brickley <danbri@google.com>:
> 
> (how could I not un-lurk for this? :)
> 
> On 19 February 2016 at 14:23, Linda van den Brink
> <l.vandenbrink@geonovum.nl> wrote:
>> Hi all,
>> 
>> Within the Geonovum testbed on spatial data on the web we have found that
>> schema.org can help make spatial data discoverable on the web. While working
>> with schema.org we noticed that most of the Things that are described with
>> schema.org are modeled without a dedicated spatial focus in mind. For
>> example the properties that describe "location" are spread over the schema,
>> and the Things that can actually have a location are limited.
> 
> Yes, location-related show up all over schema.org. I think this
> experience is not peculiar to the schema.org project -
> spatial/geo/location concepts are almost as universal as temporal
> aspects.
> 
> It is certainly true that those aspects of schema.org have not
> benefited from dedicated professional attention of experts from the
> geo-spatial domain. The terminology we have today, in part, was
> inherited via the early inclusion of the rNews vocabulary into
> schema.org (http://blog.schema.org/2011/09/extended-schemaorg-news-support.html).
> rNews in turn had some geo concepts which I think came from
> http://www.georss.org/ and perhaps originally from GML...  Along the
> way a few bugs were introduced, some of which have been fixed within
> schema.org. There also have been efforts (e.g. see last release
> http://schema.org/docs/releases.html#v2.2 ) to adapt schema.org's
> location vocabulary for more mobile services instead of assuming a
> fixed place-of-work. Previously, for example, you could describe
> various kinds of http://schema.org/LocalBusiness and their "bricks and
> mortar" physical location, but if the same services (hairdressing,
> electrician, locksmith etc.) were mobile, it was harder to describe
> the areas they could serve.  We therefore added the notion that
> http://schema.org/Service has a http://schema.org/areaServed property
> that can be (amongst other things) a http://schema.org/GeoShape such
> as http://schema.org/GeoCircle . This is still somewhat sketchy, but
> allows for example a service to be described in terms of a circle's
> metre radius from some postcode or address. Meanwhile there have also
> been a few "internet of things"-meets-schema.org conversations,
> touching on issues like description of rooms within a home or
> workplace, and their inter-relations, zones/groups etc. We are likely
> to add a basic notion of room anyway, motivated by  considerations
> around hotel bookings (see draft proposal at
> http://sdo-hotels.appspot.com/docs/hotels.html e.g.
> sdo-hotels.appspot.com/Room or /HotelRoom ). This is another example
> of the difficulty of separating spatial concerns from other schema
> areas.
> 
> While schema.org's main use cases mean we'll never go as deep into the
> spatial as e.g. GML, the project is certainly open to the idea of
> improvements informed by efforts like this WG, the Geonovum testbed
> etc.
> 
>> The folks (special thanks to Lieke Verhelst) in the testbed developed a
>> proposed extension with the idea to start from scratch. Meaning: it does not
>> propose modifications to the existing schema.org but rather seeks an
>> alternative way to model geo information into schema.org keeping in mind the
>> schema.org modeling objectives.
> 
> I'm not sure entirely how to understand "start from scratch", but if
> the idea is roughly to think through how a schema.org could/should
> handle these issues, rather than on bugfixes to our current (perhaps
> idiosyncratic) approach, that seems a perfectly reasonable and very
> useful exploration.
> 
>>    We refrain from modeling specific constructs
>> that can be used to execute a spatial analysis
> 
> Can you give an example of something you have refrained from?
> 
>> since 1) there are vocabularies that better support this
> 
> (such as?)
> 
>> and 2) search engines currently do not seem to be equipped with spatial indexes.
> 
> I'm not sure how to interpret this, but most serious search engines
> have a variety of map/geo/spatial-related associated features and
> services. How those are implemented internally does not seem
> especially relevant.
> 
>> 
>> We would be interested very much to get some comments on it from this group!
> 
> I'm not sure how much this W3C WG wants to discuss schema.org
> specifics here in the WG versus in Github but this work looks really
> interesting and I'll be nudging folk around schema.org to take a look
> and comment...
> 
> Probably the most obvious comment but here goes: it would be great to
> have a few concrete examples into the repo, particularly around
> sgeo:coordinates WKT syntax which brings us close to the GeoJSON-LD
> debates happening nearby. I would also love to get a feeling for
> whether super-local use cases (e.g. modeling inside a building) are in
> scope here. Would 'inside', 'next to', 'above' be enough to model a
> home for any useful purposes? What usecases drive the level of detail
> here?
> 
> cheers,
> 
> Dan
> 
> 
>> See https://github.com/geo4web-testbed/geo-extension-to-schemaorg

>> 
>> 
>> Linda
>

Received on Monday, 7 March 2016 12:07:12 UTC