- From: Jeremy Tandy <jeremy.tandy@gmail.com>
- Date: Wed, 02 Dec 2015 13:37:26 +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_31eU1J_xQ15FNHTsU7Y5gtcmJxWAALcHrKnZsvPuoc7A@mail.gmail.com>
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:38:07 UTC