- From: Laufer <laufer@globo.com>
- Date: Tue, 18 Mar 2014 12:09:42 -0300
- To: Makx Dekkers <mail@makxdekkers.com>
- Cc: Phil Archer <phila@w3.org>, DWBP WG <public-dwbp-wg@w3.org>
- Message-ID: <CA+pXJiiKMsTHAeFQHS-bsm1SHRFJC4wE+PvFD1OKkL34h0PwZQ@mail.gmail.com>
I prefer only one URI. An API, a SPARQL endpoint with one parameter, the SPARQL query. Laufer 2014-03-18 12:05 GMT-03:00 Makx Dekkers <mail@makxdekkers.com>: > Mapping all possible queries means assigning lots of URIs. "Please give me > the list of rooms in building A that face to the south and are available on > Sundays" etc. etc. > > Maybe we can define a kind of URI pattern as shorthand for SPARQL queries? > > Makx. > > > 2014-03-18 15:55 GMT+01:00 Laufer <laufer@globo.com>: > > 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 >>> >> >> >> >> -- >> . . . .. . . >> . . . .. >> . .. . >> > > > > -- > > -------------------------------------------------------------------------------- > Makx Dekkers > mail@makxdekkers.com > -------------------------------------------------------------------------------- > > -- . . . .. . . . . . .. . .. .
Received on Tuesday, 18 March 2014 15:10:11 UTC