Re: ACTION-96 linking to related identifiers

Awesome.

On Wed, 2 Dec 2015 at 13:44 Bill Roberts <bill@swirrl.com> wrote:

> thanks - happy to draft some suggested text for that
>
> On 2 December 2015 at 13:43, Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
>
>> Bill: see http://w3c.github.io/sdw/bp/#include-search-api ... currently
>> just the BP label only. Jeremy
>>
>> On Wed, 2 Dec 2015 at 13:37 Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
>>
>>> I can see that ...
>>>
>>> Under Exposing datasets through APIs
>>> <http://w3c.github.io/sdw/bp/#bp-exposing-via-api> we have Best
>>> Practice 28: Expose entity-level data through ‘convenience APIs’
>>> <http://w3c.github.io/sdw/bp/#convenience-apis>  which *will* say that
>>> the publisher needs to design APIs with the target consumer in mind;
>>> creating an API that does the things they need. We've not explicitly
>>> mentioned search/reconciliation; it's a good example.
>>>
>>> Thinking about this, if you _are_ going to provide an API it really
>>> would be best practice to provide a search operation. Else how do you find
>>> the specific resource you want???
>>>
>>> I'll add this to the BP doc (hoping that you'll help provide some
>>> content in due course).
>>>
>>> Jeremy
>>>
>>> On Wed, 2 Dec 2015 at 13:30 Bill Roberts <bill@swirrl.com> wrote:
>>>
>>>> Thanks Jeremy - I think you've listed the most important aspects.  One
>>>> potential additional best practice for consideration might be a
>>>> recommendation to data publishers to provide some form of
>>>> search/reconciliation API, particularly important with non-guessable URL
>>>> patterns.
>>>>
>>>> On 2 December 2015 at 13:23, Jeremy Tandy <jeremy.tandy@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Bill, Jon ...
>>>>>
>>>>> Great content along with some very useful examples that we (BP
>>>>> editors) can incorporate.
>>>>>
>>>>> I think that the subject boils down to two best practices ...
>>>>>
>>>>> From Expressing spatial data
>>>>> <http://w3c.github.io/sdw/bp/#bp-expressing-spatial> we have Best
>>>>> Practice 13: Assert known relationships
>>>>> <http://w3c.github.io/sdw/bp/#semantic-rels> which *will** say
>>>>> something along the lines of "if you know some relationships between
>>>>> (spatial) Things then publish them - because it's hard to figure out
>>>>> relationships from scratch" as your examples illustrate.
>>>>>
>>>>> And From Linking Data <http://w3c.github.io/sdw/bp/#bp-linking> we
>>>>> have Best Practice 20: Provide meaningful links
>>>>> <http://w3c.github.io/sdw/bp/#meaningful-links> (include the right
>>>>> semantics), Best Practice 21: Link to spatial Things
>>>>> <http://w3c.github.io/sdw/bp/#link-to-spatialthings> (link up the
>>>>> Things rather than the information objects that describe them e.g. geometry
>>>>> objects) and Best Practice 22: Link to resources with well-known or
>>>>> authoritative identifiers
>>>>> <http://w3c.github.io/sdw/bp/#link-to-auth-identifiers> (reference
>>>>> other people's well established resources & identifiers thereof). The
>>>>> middle one of these needs some work methinks because it's clearly useful to
>>>>> link a Thing to its geometric description ... but we want to create a
>>>>> network of related resources using the identifiers for the Things.
>>>>>
>>>>> * "will" say ... because I've not finished writing things up yet :-)
>>>>>
>>>>> Thanks Bill. Jeremy
>>>>>
>>>>> On Sun, 29 Nov 2015 at 16:11 Jon Blower <j.d.blower@reading.ac.uk>
>>>>> wrote:
>>>>>
>>>>>> Hi Bill, all,
>>>>>>
>>>>>> Just wanted to say that I found this to be an extremely helpful and
>>>>>> informative post, thanks!
>>>>>>
>>>>>> the BP document might be able to help by categorising some of the
>>>>>> most common relationships and perhaps suggest examples of appropriate
>>>>>> matching vocabulary terms.
>>>>>>
>>>>>>
>>>>>> Yes, I agree. Some of these issues are very characteristic of spatial
>>>>>> data and bang in scope for a BP document I think. We often see abuse of
>>>>>> owl:sameAs when a weaker term would be more appropriate. Enumerating the
>>>>>> options and use cases would be very helpful.
>>>>>>
>>>>>> (This has particular local relevance to us here - the University of
>>>>>> Reading is actually mostly in the Wokingham district, although most people
>>>>>> would still refer to it as part of the Reading urban area. “Colloquial
>>>>>> Reading” is different from “administrative Reading”, as it is in probably
>>>>>> most cities.)
>>>>>>
>>>>>> Cheers,
>>>>>> Jon
>>>>>>
>>>>>>
>>>>>> On 26 Nov 2015, at 18:29, Bill Roberts <bill@swirrl.com> wrote:
>>>>>>
>>>>>> Hi BP-editors
>>>>>>
>>>>>> Here are some initial thoughts on the issues of linking from your own
>>>>>> Spatial Thing to other identifiers for the same thing or related things.
>>>>>>
>>>>>> This action is to expand the text in section 7.2 of the BP draft that
>>>>>> currently says:
>>>>>>
>>>>>> "it's useful to have hyperlinks to things like Geonames, wikipedia,
>>>>>> OSM etc (see list on the mailing list, keyword: stamp collecting)"
>>>>>>
>>>>>> As per http://www.w3.org/DesignIssues/LinkedData.html item 4, it's
>>>>>> useful for people to link their data to other related data. In this context
>>>>>> we're most frequently talking about either Spatial Things and/or their
>>>>>> geometry.
>>>>>>
>>>>>> There are many useful sets of identifiers for spatial things and
>>>>>> which ones are most useful will depend on context.
>>>>>>
>>>>>> I think there are two main challenges here - discovering relevant
>>>>>> URIs that you might want to connect to, deciding what is the nature of the
>>>>>> relationship between your original URI and potential link targets, and then
>>>>>> finding an existing vocabulary term that accurately reflects that
>>>>>> relationship.
>>>>>>
>>>>>> As an example, let's take Edinburgh. In some recent work with the
>>>>>> Scottish Government, we have an identifier for the City of Edinburgh
>>>>>> Council Area - i.e. the geographical area that Edinburgh City Council is
>>>>>> responsible for:
>>>>>>
>>>>>> http://statistics.gov.scot/id/statistical-geography/S12000036
>>>>>>
>>>>>> (note that this URI doesn't resolve yet but it will in the next
>>>>>> couple of months once the system goes properly live)
>>>>>>
>>>>>> Here are some identifiers for Edinburgh and/or information about it
>>>>>> that we might want to link to, together with notes about how I found out
>>>>>> about them.
>>>>>>
>>>>>> http://statistics.data.gov.uk/id/statistical-geography/S12000036
>>>>>>
>>>>>> My identifier is directly based on this one, but the Scottish
>>>>>> Government wanted the ability to create something dereferenceable,
>>>>>> potentially with additional or different info to the data.gov.uk
>>>>>> one.  We're happy these two are owl:sameAs
>>>>>>
>>>>>> https://en.wikipedia.org/wiki/Edinburgh
>>>>>> Found by a google search for Edinburgh site:wikipedia.org).  This is
>>>>>> a page about a closely related but perhaps less specific concept of the
>>>>>> place. Possible document vs thing distinctions to be made here.  Possible
>>>>>> relationships: rdfs:seeAlso, schema:sameAs ? foaf:page?
>>>>>>
>>>>>> http://dbpedia.org/resource/Edinburgh
>>>>>> I know the pattern for changing a wikipedia URI into a dbpedia one,
>>>>>> so found it that way.  Relationship: "more or less the same as" but not
>>>>>> sure I'd want to go as far as the strict semantics of owl:sameAs
>>>>>>
>>>>>> http://data.ordnancesurvey.co.uk/id/50kGazetteer/81482 (Edinburgh)
>>>>>> Found by OS gazetteer search service for 'Edinburgh' then checking
>>>>>> the labels of the results that came up.  OS give it a type of 'NamedPlace'
>>>>>> and give it some coordinates.
>>>>>>
>>>>>> http://data.ordnancesurvey.co.uk/id/50kGazetteer/81483 (Edinburgh
>>>>>> airport)
>>>>>> Also found by the same OS gazetteer search service for 'Edinburgh'.
>>>>>> This is clearly not the same as my original spatial thing, but I might want
>>>>>> to say something like 'within' or 'hasAirport'.
>>>>>>
>>>>>> http://data.ordnancesurvey.co.uk/id/7000000000030505
>>>>>> Found by a search for 'Edinburgh' in the OS 'Boundary Line' service
>>>>>> that contains administrative and statistical geography areas in the UK.
>>>>>> The first results of the search were parliamentary constituencies - had to
>>>>>> scroll down and look for one that had a stated rdf:type that matched what I
>>>>>> was looking for.  It's probably safe to say my identifier is owl:sameAs
>>>>>> this one.
>>>>>>
>>>>>> http://sws.geonames.org/2650225/
>>>>>> Found with the Geonames search service:
>>>>>> http://api.geonames.org/search?name=Edinburgh&type=rdf&username=demo
>>>>>> Once you have found a place in geonames, there are other useful
>>>>>> services to find things that are nearby etc. Not sure exactly what this is,
>>>>>> though it has a RDF type of http://www.geonames.org/ontology#Feature
>>>>>>
>>>>>> http://www.openstreetmap.org/relation/1920901  (administrative
>>>>>> boundary)
>>>>>> machine readable data:
>>>>>> http://www.openstreetmap.org/api/0.6/relation/1920901
>>>>>> Found via the search box at www.openstreetmap.org.
>>>>>> see also
>>>>>> http://nominatim.openstreetmap.org/details.php?place_id=127903534
>>>>>> and http://www.openstreetmap.org/node/17898859 (node - somewhere
>>>>>> around the centre of Edinburgh)
>>>>>> I'm not sure of all the options with OSM - I'm sure others in the WG
>>>>>> know more -but it has identifiers for nodes, ways and relations, though it
>>>>>> seems that these identifiers tend to change quite frequently as the map is
>>>>>> edited.
>>>>>>
>>>>>> The outcome of this example is that it takes a bit of prior knowledge
>>>>>> and intelligent manual guesswork to find related URIs.  Some services, eg
>>>>>> OS, have useful search facilities, but the results may still need some
>>>>>> interpretation. Recommending some standard approach to providing a search
>>>>>> facility (or 'reconciliation API') for a collection of spatial data might
>>>>>> be a useful best practice.
>>>>>>
>>>>>> Working out how to accurately describe the relationship is hard in
>>>>>> general and the BP document might be able to help by categorising some of
>>>>>> the most common relationships and perhaps suggest examples of appropriate
>>>>>> matching vocabulary terms.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>