- From: Jeremy Tandy <jeremy.tandy@gmail.com>
- Date: Wed, 02 Dec 2015 13:43:02 +0000
- To: Bill Roberts <bill@swirrl.com>
- Cc: Jon Blower <j.d.blower@reading.ac.uk>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
- Message-ID: <CADtUq_1Hg9ZvDiRTSQMG8chOT0oP=5ZWxrWTMbdupfiefAuu_A@mail.gmail.com>
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. >>>> >>>> >>>> >>>> >>>> >>
Received on Wednesday, 2 December 2015 13:43:41 UTC