Re: APIs to work with data on the web

You can encode a SPARQL query in a URI [1] but that's not what I had in 
mind.

Take my post code (zip code). Its URI is:

http://data.ordnancesurvey.co.uk/id/postcodeunit/IP45TW

When you dereference that, after a 303 redirect to

http://data.ordnancesurvey.co.uk/doc/postcodeunit/IP45TW

(notice that /id/ has become /doc/) you get information *about* the 
place where I am right now. Through content negotiation, it's available 
in multiple formats (HTML, JSON, Turtle or RDF/XML) from that same URI 
or, if you want to specify a format, add its file extension to the URI. 
The data is extracted from the data using a SPARQL query that runs in 
the background that the user never sees (and doesn't need to see).

We can add any number of new formats to that data service and indeed 
throw away the whole Linked data back end if we want to and translate 
the URI into some other query language - the URI remains the same.

So in some senses that URI *is* an API. It's also an identifier for a 
little chunk of England.

Hope I'm not teaching you to suck eggs here*

Phil

[1] http://www.w3.org/TR/sparql11-protocol/

* That's an expression that came up in a call earlier today. 'Teaching 
your grandmother to suck eggs' is an English phrase meaning to tell 
someone how to do something they already know perfectly well how to do, 
in a very patronising way.

On 18/03/2014 14:55, Laufer wrote:
> Hi Phil,
>
> It is a way to embed the query in the URI. Could we have all possible
> queries mapped?
>
> Best,
> Laufer
>
>
> 2014-03-18 11:51 GMT-03:00 Phil Archer <phila@w3.org>:
>
>> I think that there are a number of possible answers to your question,
>> Laufer. The one that I immediately think of is the Linked data API [1]
>> which provides a framework for the kind of thing you refer to here. It maps
>> URIs to SPARQL queries that can return lists of 'everything below here in
>> the graph.'
>>
>> There are a few implementations of the Linked Data API, one that gets most
>> attention these days is ELDA [2].
>>
>> An alternative URI -> SPARQL mapping tool is Pubby [3] which is used by
>> DBPedia (it's from the same team).
>>
>> To take a fictitious example, I agree it would be nice if:
>>
>> http://data.example.com/id/building/A/rooms
>>
>> returned a list of all the rooms in building A
>>
>> http://data.example.com/id/building/A/rooms/ground
>>
>> returned a list of all the rooms on the ground floor of building A
>>
>> http://data.example.com/id/building/A/rooms/ground/01
>>
>> identified room 01 on the ground floor of building A.
>>
>> That's a nice thing to set up, and using something like the tools listed
>> above is certainly possible. It conflates URI design with implementation
>> (which may or may not be a good thing). Whether that's an actual Best
>> Practice... is for the WG to decide :-)
>>
>> Phil.
>>
>> [1] https://code.google.com/p/linked-data-api/
>> [2] http://www.epimorphics.com/web/tools/elda.html
>> [3] http://wifo5-03.informatik.uni-mannheim.de/pubby/
>>
>>
>> On 18/03/2014 14:23, Laufer wrote:
>>
>>> Steve, Manuel,
>>>
>>> I am not talking only about the Resources. Or, what are the things that
>>> are
>>> exposed as Resources.
>>>
>>> For example, in DBpedia there is a Resource for the album Houses of the
>>> Holy (http://dbpedia.org/page/Houses_of_the_Holy).
>>> There is also a Resource for the record label Atlantic Records (
>>> http://dbpedia.org/page/Atlantic_Records), which is the record label from
>>> the album Houses of the Holy.
>>>
>>> What is the URI of all albums of the record label Atlantic Records?
>>>
>>> My question is: could it be one Best Practice, recommended by of DWBP WG,
>>> to provide a way of exposing the "Resource" All Albums of the Record Label
>>> Atlantic Records?
>>>
>>> Best Regards,
>>> Laufer
>>>
>>>
>>>
>>>
>>> 2014-03-18 10:18 GMT-03:00 Steven Adler <adler1@us.ibm.com>:
>>>
>>>   Thanks.  A few people have agreed with our position below, but some still
>>>> like the idea of API's for accessing Data.  What is the process W3C uses
>>>> to
>>>> resolve these points of view and when it is resolved, does the conclusion
>>>> get written into the Best Practices draft and/or do we also include the
>>>> lineage of the conclusion - that is, we we present the pros and cons and
>>>> reasons for the conclusion by also relating what we didn't recommend and
>>>> why?
>>>>
>>>>
>>>> Best Regards,
>>>>
>>>> Steve
>>>>
>>>> Motto: "Do First, Think, Do it Again"
>>>>
>>>>
>>>>    From: <Manuel.CARRASCO-BENITEZ@ec.europa.eu> To: Steven
>>>> Adler/Somers/IBM@IBMUS, <Deirdre.Lee@deri.org> Cc: <mail@makxdekkers.com
>>>>> ,
>>>> <newton@nic.br>, <public-dwbp-wg@w3.org> Date: 03/18/2014 08:21 AM
>>>> Subject: RE: APIs to work with data on the web
>>>> ------------------------------
>>>>
>>>>
>>>>
>>>>
>>>> +1
>>>>
>>>> -        Resources should be addressable with a URI
>>>> -        One should aim a common interface for humans and machine
>>>>
>>>> *http://www.w3.org/2013/dwbp/wiki/Data_on_the_Web_URI_Best_Practices*<
>>>> http://www.w3.org/2013/dwbp/wiki/Data_on_the_Web_URI_Best_Practices>
>>>>
>>>> Regards
>>>> Tomas
>>>>
>>>> *From:* Steven Adler [mailto:adler1@us.ibm.com <adler1@us.ibm.com>]
>>>> * Sent:* Monday, March 17, 2014 4:34 PM
>>>> * To:* Lee, Deirdre
>>>> * Cc:* Makx Dekkers; Newton Calegari; public-dwbp-wg@w3.org
>>>> * Subject:* RE: APIs to work with data on the web
>>>>
>>>>
>>>> Excellent use case which begins to explore and spell out the advantages
>>>> and trade-offs of using API's to access Open Data.  I would like to
>>>> explore
>>>> this topic in greater detail.  My own personal preference is data access
>>>> by
>>>> HTTP and URI, because it provides a common interface for humans and
>>>> machines.  But are there performance implications?
>>>>
>>>>
>>>> Best Regards,
>>>>
>>>> Steve
>>>>
>>>> Motto: "Do First, Think, Do it Again"
>>>>
>>>>    From: "Lee, Deirdre" <*Deirdre.Lee@deri.org* <Deirdre.Lee@deri.org>>
>>>>   To: Newton
>>>> Calegari <*newton@nic.br* <newton@nic.br>>, Makx Dekkers <
>>>> *mail@makxdekkers.com* <mail@makxdekkers.com>>  Cc: "
>>>> *public-dwbp-wg@w3.org* <public-dwbp-wg@w3.org>" <*public-dwbp-wg@w3.org
>>>> *<public-dwbp-wg@w3.org>
>>>>
>>>>     Date: 03/17/2014 11:19 AM  Subject: RE: APIs to work with data on the
>>>>>
>>>> web
>>>>
>>>> ------------------------------
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> Very interesting article indeed and related to discussions we're
>>>> currently
>>>> having with developers as part of Open Data Ireland on how best to
>>>> publish/use machine-readable data.
>>>>
>>>> I've added a use-case on it *https://www.w3.org/2013/dwbp/
>>>> wiki/Use_Cases*<https://www.w3.org/2013/dwbp/wiki/Use_Cases>Please feel
>>>> free to add points or pick up on nuances of the conversation
>>>>
>>>> that I missed. Perhaps we could break this into multiple use-cases to
>>>> look
>>>> at each of the aspects in more detail?
>>>>
>>>> Cheers,
>>>> Deirdre
>>>>
>>>>
>>>> * From:* Newton Calegari [*mailto:newton@nic.br* <newton@nic.br>]
>>>> * Sent:* 17 March 2014 13:19
>>>> * To:* Makx Dekkers
>>>> * Cc:* *public-dwbp-wg@w3.org* <public-dwbp-wg@w3.org>
>>>> * Subject:* Re: APIs to work with data on the web
>>>>
>>>>
>>>> Hi Laufer, I didn't know the Socrata.
>>>> Thanks for share the link, Makx. Very interesting text and point of view
>>>> about APIs.
>>>>
>>>> BR,
>>>>
>>>> Newton
>>>>
>>>> Em 14/03/2014, à(s) 15:58, Makx Dekkers <*mail@makxdekkers.com*<mail@
>>>> makxdekkers.com>>
>>>>
>>>> escreveu:
>>>>
>>>>
>>>> For a different perspective on APIs, see this:
>>>> *http://ruben.verborgh.org/blog/2013/11/29/the-lie-of-the-api/*<
>>>> http://ruben.verborgh.org/blog/2013/11/29/the-lie-of-the-api/>
>>>>
>>>> Makx.
>>>>
>>>> * From:* Newton Calegari [*mailto:newton@nic.br* <newton@nic.br>]
>>>> * Sent:* Thursday, March 13, 2014 6:03 PM
>>>> * To:* *public-dwbp-wg@w3.org* <public-dwbp-wg@w3.org>
>>>> * Subject:* APIs to work with data on the web
>>>>
>>>>
>>>> Hi all,
>>>>
>>>>            Last week, Yaso and I were talking about APIs and how they are
>>>> important in all aspects of data on the web. APIs are one of the simplest
>>>> ways to access and to distribute data across the web, and we think that
>>>> is
>>>> an important subject to be discussed on the WG.
>>>>            To talk about APIs, we obviously need to discuss about URI and
>>>> descriptors. Carrasco written the first document [*1*<
>>>> http://www.w3.org/2013/dwbp/wiki/Data_on_the_Web_URI_Best_Practices>]
>>>>
>>>> about it, besides there are a few messages discussing it.
>>>>            Moreover, I want to share some links I consider relevant and
>>>> useful to discuss about this topic.
>>>>            Joshua Bloch, a software engineer and former *Googler*,
>>>> published an article on InfoQ [*2*<http://www.infoq.com/
>>>> articles/API-Design-Joshua-Bloch?utm_source=buffer&utm_
>>>> campaign=Buffer&utm_content=buffer36801&utm_medium=
>>>> twitter#.UvbdCPy0BT0.delicious>]
>>>>
>>>> site and made a presentation called "How to Design a Good API & Why it
>>>> Matters" [*3* <http://www.infoq.com/presentations/effective-api-design>]
>>>>
>>>> (other Jushua's presentation about the same subject, but the video is
>>>> hosted on YouTube [*4* <https://www.youtube.com/watch?v=aAb7hSCtvGw>]).
>>>>
>>>> These links are very interesting and I recommend to all of you, even who
>>>> is
>>>> already expert in API design.
>>>>
>>>> [1] Data on the Web URI Best Practices:
>>>> *http://www.w3.org/2013/dwbp/wiki/Data_on_the_Web_URI_Best_Practices*<
>>>> http://www.w3.org/2013/dwbp/wiki/Data_on_the_Web_URI_Best_Practices>
>>>>
>>>> [2] Joshua Bloch: Bumper-Sticker API Design:
>>>> *http://www.infoq.com/articles/API-Design-Joshua-
>>>> Bloch?utm_source=buffer&utm_campaign=Buffer&utm_content=
>>>> buffer36801&utm_medium=twitter#.UvbdCPy0BT0.delicious*<http://www.infoq.
>>>> com/articles/API-Design-Joshua-Bloch?utm_source=
>>>> buffer&utm_campaign=Buffer&utm_content=buffer36801&utm_
>>>> medium=twitter#.UvbdCPy0BT0.delicious>
>>>>
>>>> [3] How to Design a Good API & Why it Matters:
>>>> *http://www.infoq.com/presentations/effective-api-design*<
>>>> http://www.infoq.com/presentations/effective-api-design>
>>>>
>>>> [4] How to Design a Good API & Why it Matters (YouTube version):
>>>> *https://www.youtube..com/watch?v=aAb7hSCtvGw*<https://
>>>> www.youtube.com/watch?v=aAb7hSCtvGw>
>>>>
>>>> Best Regards,
>>>> Newton
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>> --
>>
>>
>> Phil Archer
>> W3C Data Activity Lead
>> http://www.w3.org/2013/data/
>>
>> http://philarcher.org
>> +44 (0)7887 767755
>> @philarcher1
>>
>
>
>

-- 


Phil Archer
W3C Data Activity Lead
http://www.w3.org/2013/data/

http://philarcher.org
+44 (0)7887 767755
@philarcher1

Received on Tuesday, 18 March 2014 15:17:42 UTC