AW: LLD Web Services

About OpenSearch, I'm not sure if it helps so much. In an particular wide spread use case - autosuggest services for authorities - I found no clean way to code the 3 response elements according to the OpenSearch "Suggestions" extension spec. (I wanted to provide 1. matched string, possibly an alt or hidden label, 2. the preferred label and 3. the URI). In general (as far as I got it), the OpenSearch response format is extensible, which most non-trivial cases requires custom-coded agents anyway. 

Therefore, I added the Linked Data API and the W3C RDF/RDFa APIs under current development to http://www.w3.org/2005/Incubator/lld/wiki/Draft_Relevant_Technologies#Web_Services_for_Library_Linked_Data. To get not overly long, I'd drop the hints about replacements for SPARQL/Update, where the requirement is not so wide spread. 

My feeling is that there is no silver bulltet, and it has to turn out which approaches fit best in practice.

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:33:39 UTC