RE: LLD Web Services

Joachim,

These are great points and your changes look good. Thanks!

Jeff

> -----Original Message-----
> From: Neubert Joachim [mailto:J.Neubert@zbw.eu]
> Sent: Tuesday, May 10, 2011 11:05 AM
> To: Young,Jeff (OR); Ford, Kevin; public-lld@w3.org
> Subject: AW: LLD Web Services
> 
> Hi Jeff,
> 
> Thanks for adding and tweaking our text. However, the main idea of
> http://www.w3.org/2005/Incubator/lld/wiki/Web_services_on_LLD was that
> simple Web Services are important for the spreading the re-use of LLD,
> for two main reasons:
> 
> 
> SPARQL backends and production environments
> 
> There are good reasons why organizations generally do not offer SQL
> access to their databases: In a general query language such as SQL or
> SPARQL, it is very easy to construct queries that force a server down
> by sheer load. This happens even if we assume that all users are good-
> willing - simple mistakes or missing knowledge about the physical data
> access paths (indexes defined) makes it very likely. My feeling is that
> the counter strategies implemented in SPARQL servers (cutting results
> after a certain number of triples and/or after a certain amount of CPU
> usage and/or restricting the types of queries) are far from mature and
> more like makeshifts.
> 
> For a production implementation, the owners have to guarantee reliable
> access and a certain quality of service. So in my eyes powerful SPARQL
> interfaces are currently limited to labs environments, in order to
> discover useful access patterns and queries, or to drive other
> experimental implementations. The patterns discovered possibly could
> push the further evolution of production quality web services. So, in
> my point of view, SPARQL endpoints *are* useful and *should* be
> offered, but are at the same time very limited in scope. (Even for
> medium sized datasets such as authorities - as far as I know, neither
> DNB nor VIAF offer SPARQL access to their datasets).
> 
> 
> Developer skills
> 
> As the authors of the Linked Data API (thanks, Richard, for the hint)
> put it: "Simple RESTful APIs are well supported and understood by a
> large community of web developers. Faced with Linked Data and SPARQL
> endpoints this community faces a steep learning curve before they are
> able to make use of the power provided by the underlying technologies.
> Put differently, SPARQL is a power tool whose sophistication is
> unnecessary for many users."
> 
> Our main goal should be to offer Linked Data URIs, to aid their
> proliferation and to demonstrate the enableing power of Linked Data -
> lowering the entry barrier by not requesting a complete new
> technologies skillset ("making it much less foreign and frightening",
> as Karen put it).
> 
> 
> I've tried to integrate these aspects into the wiki text. It would be
> great if we can agree so far - otherwise please feel free to tweak it
> again.
> 
> Cheers, Joachim
> 
> 
> 
> 
> > -----Ursprüngliche Nachricht-----
> > Von: public-lld-request@w3.org
> > [mailto:public-lld-request@w3.org] Im Auftrag von Young,Jeff (OR)
> > Gesendet: Montag, 9. Mai 2011 18:29
> > An: Ford, Kevin; public-lld
> > Betreff: RE: LLD Web Services
> >
> > I added Kevin and Joachim's text to the Draft Relevant
> > Technologies page and tweaked it a bit. I'm afraid I made it
> > less readable, but hopefully tied up a few loose ends in
> > exchange. If the changes are too radical, I can back them out.
> >
> > Suggestions and help for making the text readable again would
> > be very welcome. Also, a few questions/issues popped out that
> > could use some broader opinions. They appear in brackets in the text:
> >
> > http://www.w3.org/2005/Incubator/lld/wiki/Draft_Relevant_Techn
> > ologies#We
> > b_Services_for_Library_Linked_Data
> >
> > Jeff
> >
> > > -----Original Message-----
> > > From: public-lld-request@w3.org
> > [mailto:public-lld-request@w3.org] On
> > > Behalf Of Ford, Kevin
> > > Sent: Thursday, May 05, 2011 9:43 AM
> > > To: public-lld
> > > Subject: LLD Web Services
> > >
> > > Dear All,
> > >
> > > Joachim contacted me and asked, based on discussion during
> > a telecon,
> > > if I could trim the Web Services text he and I authored for
> > inclusion
> > > into the final report.  After reviewing the minutes of that
> > telecon, I
> > > am operating under the assumption that it is to go in the Relevant
> > > Technologies section of the report (or, at least what appears to be
> > the
> > > current draft) [1].  I hope so: I've tried to tailor it to that
> > > section.  I see it going after "Linked Data front-ends to existing
> > data
> > > stores" and before "OWL and supporting tools".  I've halved
> > the text
> > > (at least).  I'm having a devil of a time signing in to the wiki
> > > currently, so I've pasted it below.  If someone wants to
> > paste it into
> > > the document, that would be great.
> > >
> > > Warmly,
> > >
> > > Kevin
> > >
> > > [1]
> > >
> > http://www.w3.org/2005/Incubator/lld/wiki/Draft_Relevant_Technologies
> > >
> > >
> > > Web Services for LLD
> > >
> > > Many LD implementations, for a variety of reasons, can not
> > or have not
> > > provided SPARQL endpoints (or bulk downloads).  Some LD
> > implementations
> > > might not use a triplestore in the back-end, which is seen as a
> > natural
> > > precursor for a SPARQL endpoint; for others, security or robustness
> > > considerations preclude such a feature in production use.  Not
> > offering
> > > these options can hinder further resource discovery.
> > Furthermore, it
> > > may also not be feasible to layer a Linked Data front-end on to an
> > > existing back-end.
> > >
> > > Therefore LLD efforts should encourage the development of LD Web
> > > Services to facilitate greater access to the data offered by a LD
> > > Implementation.  Web Services can be offered in the absence of a
> > SPARQL
> > > endpoint or in conjunction with one.   Web Services should be fully
> > > documented.
> > >
> > > A few LD implementations have endeavored to implement Web
> > Services to
> > > enhance discovery and use of resources, often by providing some
> form
> > of
> > > an application programming interface (API).  Agrovoc and STW
> provide
> > an
> > > API to discover resources based on relationships in the data, among
> > > many more web services.  VIAF, LC's ID, and STW offer autosuggest
> > > services for resources, delivering JSON responses ready for
> > consumption
> > > in AJAX browser applications.  Agrovoc and STITCH/CATCH include
> > support
> > > for pure RDF responses.  Some services provide full-fledged
> > SOAP APIs,
> > > while others support a REST approach.
> > >
> > > By focusing on method parameters and response formats to provide
> > > enhanced discovery, LD Web Services diminish, if not eliminate, the
> > > requirement that data be stored in a triplestore.  And, because web
> > > service APIs are common, web services can lower the barrier
> > to entry.
> > >
> > >
> >
> >
> >
> >

Received on Tuesday, 10 May 2011 15:15:37 UTC