RE: LLD Web Services

It reads ok to me. I want to point out that this paragraph:

"However web developers are sometimes turned off Semantic Web (Linked  
Data) technologies because they feel like they would need to throw  
away their current application, to swap their database for a  
triplestore, and their database query language for SPARQL. This is  
simply not the case, since RDF serializations can be generated on the  
fly just as web application frameworks do fo HTML, XML and JSON  
representations. The use of http URIs to identify and link together  
resources in RDF's data model make it a natural choice for serializing  
and sharing entity state in a database neutral way--which has  
traditionally been of great interest to cultural heritage  
organizations and the digital preservation community. "

totally parallels a discussion we just had in the LLD recommendations  
group, and which perhaps should also be included in the benefits area.  
Our discussion in LLD-R was that we should emphasize what some library  
practices, like authority control and controlled terms, and LD with  
URIs have in common -- for identification, for sharing (and the  
subsequent efficiencies), and for re-use. If we can present those  
concepts as being a new way to do what libraries already have in their  
metadata toolkit, we make it much less foreign and frightening.

kc

Quoting "Young,Jeff (OR)" <jyoung@oclc.org>:

> 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_Technologies#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.
>>
>>
>
>
>
>



-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Monday, 9 May 2011 17:21:29 UTC