Re: APIs to work with data on the web

Manuel,

I am not against URIs. They are the core.

But I think that it would be very difficult to a developer to guess what
would be the URIs of all the collections that she could get from the
datasets. For me, that's one reason to have a SPARQL endpoint instead of
having plan URIs for all possible queries.

Even if you don't have a SPARQL endpoint you will need a mapping to show
how to map a query to a URI. It could be considered a kind of query to URI
transformation. If you published the mapping schema to be read by a human,
we could say that the API is executed by the human that read the
documentation. In a scenario, we can think in an API that would receive a
SPARQL query and will return a URI. If a developer has the schema of the
dataset (I am talking about rdf), she could ask whatever she wants. In the
case that are few possibilities of different queries maybe only the URIs
could be sufficient.

I prefer a mix of URIs with a very basic set of APIs (I don't know the
blend). And a very good documentation.

Best,
Laufer



2014-03-19 7:01 GMT-03:00 <Manuel.CARRASCO-BENITEZ@ec.europa.eu>:

>  Laufer,
>
>
>
> Let's look at URI and resource
>
>   *Uniform Resource Identifier (URI): Generic Syntax*
>
>   http://tools.ietf.org/html/rfc3986
>
>
>
> *"A URI is an identifier consisting of a sequence of characters ..."*
>
> *" 'resource' is used in a general sense for whatever might be identified
> by a URI ..."*
>
>
>
> *URI* is not just query;  HTTP is just one of many schemes
>
>   *Uniform Resource Identifier (URI) Schemes*
>
>    http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
>
>
>
> *Resource* might be viewed as a package: many variants (e.g., several
> languages) and useful information to provide metadata, context, etc.
>
>
>
> We should address Linked Data (technical) and Linked *Open* Data (legal)
> in different layers: the 5 starts are in the legal layer
>
>   http://www.w3.org/DesignIssues/LinkedData.html
>
>
>
> Let's consider URI with any scheme, though HTTP is the main protocol and
> Linked Data paper states to "*Use HTTP URIs* ...".
>
>
>
> In a plain practical way: getting access to the data with simple,
> permanent, short HTTP URI is refreshing J
>
>
>
> Regards
>
> (Manuel) Tomas
>
>
>
>
>
> *From:* Laufer [mailto:laufer@globo.com]
> *Sent:* Tuesday, March 18, 2014 5:30 PM
> *To:* CARRASCO BENITEZ Manuel (DGT)
> *Cc:* Steven Adler; deirdre.lee; Makx Dekkers; Newton Calegari; DWBP WG
>
> *Subject:* Re: APIs to work with data on the web
>
>
>
> Tomas,
>
> I understand completely your point.
>
> But I disagree. To me, it is not refreshing to represent a query using an
> URI. Think about all the groupings that you can make over a dataset or
> datasets.
>
> Best,
>
> Laufer
>
>
>
> 2014-03-18 13:18 GMT-03:00 <Manuel.CARRASCO-BENITEZ@ec.europa.eu>:
>
> Laufer,
>
>
>
> Going back to basics, the four point could be crashed into two
>
>  http://www.w3.org/DesignIssues/LinkedData.html
>
>
>
> a)      Use URIs to name and to point into things (resources)
>
> b)      Provide useful information as links (metadata, origin, etc)
>
>
>
> Note that one URI could have many variants: languages, formats, time
> (memento), etc. So
>
>
>
> Get the "best" variant
>
>   http://example.com/1122
>
>
>
> Get the useful information
>
>   http://example.com/1122?info
>
>
>
> Get some specific variants
>
>   http://example.com/1122.fr
>
>   http://example.com/1122.xhtml
>
>   http://example.com/1122.es.txt
>
>   It is very refreshing to type an URI and get the "thing", even if
> sometimes one would prefer a forgetful  web J
>
>
> http://lists.w3.org/Archives/Public/www-international/1997JanMar/0053.html
>
>
>
> As you can see, it is a subject with some pedigree.
>
>
>
> Regards
>
> Tomas
>
>
>
>
>
> *From:* Laufer [mailto:laufer@globo.com]
> *Sent:* Tuesday, March 18, 2014 3:24 PM
> *To:* Steven Adler
> *Cc:* CARRASCO BENITEZ Manuel (DGT); Deirdre.Lee@deri.org;
> mail@makxdekkers.com; Newton Calegari; DWBP WG
>
>
> *Subject:* Re: APIs to work with data on the web
>
>
>
> 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
>
> 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>
>
> To:
>
> Newton Calegari <newton@nic.br>, Makx Dekkers <mail@makxdekkers.com>
>
> Cc:
>
> "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_CasesPlease 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
> * 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> escreveu:
>
>
> For a different perspective on APIs, see this:
> 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
> * 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
> [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
> [3] How to Design a Good API & Why it Matters:
> 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
>
>
>
>
>
> --
> .  .  .  .. .  .
> .        .   . ..
> .     ..       .
>
>
>
>
> --
> .  .  .  .. .  .
> .        .   . ..
> .     ..       .
>



-- 
.  .  .  .. .  .
.        .   . ..
.     ..       .