Re: ACTION-96 linking to related identifiers

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