Re: APIs to work with data on the web

Hi Laufer and Steven,

There are two specifications that I think is very interesting to take a
look. The first one if the Linked Data Platform 1.0 [1], with the Working
Draft from this month which brings two concepts: The Linked Data Platform
Container [2], which group several concepts in a container and it can be
retrieved with only one URI (or IRI) and the Linked Data Platform Paging
[3] (and editor draft from today), which is exactly for large resources.

Another specification is RDF 1.1 [4] Specification, which provides the
concept of RDF Dataset and I can combine diferent resources and datasets
with only one IRI (loog this example [5] in the spec). It is also possible
to increment new resources to the RDF Dataset by using TriG [6].

[1] http://www.w3.org/TR/ldp/#bib-LDP-PAGING
[2] http://www.w3.org/TR/ldp/#ldpc
[3] https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-paging.html
[4] http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/
[5]
http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/#section-multiple-graphs
[6] http://www.w3.org/TR/2014/REC-trig-20140225/Overview.html

Best,
Ig


2014-03-19 10:17 GMT-03:00 Steven Adler <adler1@us.ibm.com>:

> Laufer,
>
> You raise a very good point.  It would become extremely complex to have to
> access large datasets via URI's, but is SPARQL the only way to do this?  I
> ask because IBM just discontinued RDF support in DB2 due to inadequate
> customer demand.  I am not personally biased against RDF because there may
> be many reasons for IBM's decision:
>
> 1.  We may not have marketed this capability.
> 2.  DB2 may be too expensive or heavy for RDF use cases.
> 3.  RDF users may not think about DB2 as their first choice in databases,
>  etc.
>
> But I also have anecdotal developer stories that they do not like working
> with RDF.  So even though SPARQL is a very elegant way to gather up and
> represent many URI's I would prefer if we also had other non-RDF methods
> highlighted in our recommendations.
>
> Is that possible?
>
>
> Best Regards,
>
> Steve
>
> Motto: "Do First, Think, Do it Again"
>
>
>  From: Laufer <laufer@globo.com> To: "manuel.carrasco-benitez" <
> Manuel.CARRASCO-BENITEZ@ec.europa.eu> Cc: Steven Adler/Somers/IBM@IBMUS,
> "deirdre.lee" <Deirdre.Lee@deri.org>, Makx Dekkers <mail@makxdekkers.com>,
> Newton Calegari <newton@nic.br>, DWBP WG <public-dwbp-wg@w3.org> Date: 03/19/2014
> 08:19 AM Subject: 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*<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*<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*<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*<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* <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*<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*<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* <http://example.com/1122>
>
> Get the useful information
>   *http://example.com/1122?info* <http://example.com/1122?info>
>
>
>
> Get some specific variants
>   *http://example.com/1122.fr* <http://example.com/1122.fr>
>   *http://example.com/1122.xhtml* <http://example.com/1122.xhtml>
>   *http://example.com/1122.es.txt* <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*<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* <laufer@globo.com>]
> * Sent:* Tuesday, March 18, 2014 3:24 PM
> * To:* Steven Adler
> * Cc:* CARRASCO BENITEZ Manuel (DGT); *Deirdre.Lee@deri.org*<Deirdre.Lee@deri.org>;
> *mail@makxdekkers.com* <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*<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*<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*<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*<Manuel.CARRASCO-BENITEZ@ec.europa.eu>
> >  To: Steven Adler/Somers/IBM@IBMUS, <*Deirdre.Lee@deri.org*<Deirdre.Lee@deri.org>
> >  Cc: <*mail@makxdekkers.com* <mail@makxdekkers.com>>, <*newton@nic.br*<newton@nic.br>>,
> <*public-dwbp-wg@w3.org* <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*<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
>
>
>
>
>
> --
> .  .  .  .. .  .
> .        .   . ..
> .     ..       .
>
>
>
>
> --
> .  .  .  .. .  .
> .        .   . ..
> .     ..       .
>
>
>
>
> --
> .  .  .  .. .  .
> .        .   . ..
> .     ..       .
>
>


-- 

Ig Ibert Bittencourt
Professor Adjunto III - Universidade Federal de Alagoas (UFAL)
Vice-Coordenador da Comissão Especial de Informática na Educação
Líder do Centro de Excelência em Tecnologias Sociais
Co-fundador da Startup MeuTutor Soluções Educacionais LTDA.