W3C home > Mailing lists > Public > public-lld@w3.org > May 2011

Re: Review of Draft recommendation page

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Wed, 25 May 2011 08:09:58 -0700
Message-ID: <20110525080958.32973h7zl1o3tdc6@kcoyle.net>
To: public-lld@w3.org

Thanks. While I don't think we want to get into the detail in our  
report, I will look to see if we can work in something about practices  
that smooth the transition. Some of these are already coming up around  
the initial use of RDA, but I don't know of any discussion of how that  
fits into LD. Getting catalogers to think about LD even though they  
are cataloging in current formats would be an important step forward.


Quoting Owen Stephens <owen@ostephens.com>:

> I don't think necessarily this is the right place for it, but this  
> prompted me to wonder - is there any scope for making  
> recommendations in terms of current data practices that might be  
> adopted to better enable move to LD for libraries?
> This is something we've been discussing with cataloguers following  
> our work in the Lucero project and based on our experience of trying  
> to convert MARC to LD
> - thinking of things like... In MARC21:
> Use X00 $$4 and X10 $$4 to indicate relationship between person and  
> item catalogued
> Include Authority identifier $$0 in all applicable fields - e.g.  
> 100; 650 etc. etc. (to enable linking to authority sources such as  
> Ensure accurate use of fixed length fields (LDR, 006, 007, 008 etc.)
> There are quite a few places in MARC where identifiers or encoded  
> values can be recorded, which would map to existing LD URIs - the  
> more these are filled out, the easier a useful transformation to LD  
> might be
> Any support for this idea? Or is it out of scope/too late?
> Owen
> Owen Stephens
> Owen Stephens Consulting
> Web: http://www.ostephens.com
> Email: owen@ostephens.com
> Telephone: 0121 288 6936
> On 25 May 2011, at 04:58, Young,Jeff (OR) wrote:
>> I have an action to review the draft recommendations page:
>> http://www.w3.org/2005/Incubator/lld/wiki/Draft_recommendations_page
>> Here are some section-by-section thoughts. In several cases the  
>> thought was eventually addressed, so it’s probably safe to ignore  
>> those. In general, I think the section is excellent!
>> Recommendations (1st paragraph)
>> I’ll try to avoid word-smithing, but I would suggest changing  
>> “libraries can take on a leadership role around traditional library  
>> values of…” to “libraries can leverage their traditional values of…”.
>> Identify sets of data as possible candidates for early exposure as LD
>> One guideline here may be encourage developers to focus on  
>> resources that are likely to be found in Linked Data cloud hubs.  
>> The mental block that needs to be overcome is knowing the hubs  
>> probably don’t contain every instance needed, but developers  
>> shouldn’t let that be a show-stopper. [I see this is mentioned in  
>> the section named “Create explicit links from …]
>> For each set of data, determine the ROI…
>> In terms of ROI, replacing MARC bibliographic format will  
>> presumably be more hateful than other data formats. This is implied  
>> in various places, but this section might be less discouraging in  
>> general if the point was acknowledged.
>> Increase library participation in Semantic Web standardization
>> This section mentions extending standards, presumably in the sense  
>> of library community extensions. One of the nice things about OWL,  
>> though, is that domain-specific terms can also be mapped to other  
>> terms without community involvement. I think this is a useful point  
>> because many developers still seem to believe that existing  
>> vocabularies are all-or-nothing. [I see this is mentioned in the  
>> “Directly use, or map to,…” section.]
>> Develop best practices and design patterns for LLD
>> Assuming heterogeneity is inevitable, an OWL reasoner could be used  
>> in combination with OWL mappings to smooth out dataset mashups.
>> Commit to best-practice policies for managing and preserving RDF  
>> vocabularies
>> I’m not sure what this bullet means:
>> ·         Extensibility of use of the namespace by smaller organizations
>> Jeff
>> ---
>> Jeffrey A. Young
>> Software Architect
>> OCLC Research, Mail Code 410
>> OCLC Online Computer Library Center, Inc.
>> 6565 Kilgour Place
>> Dublin, OH 43017-3395
>> www.oclc.org
>> Voice: 614-764-4342
>> Voice: 800-848-5878, ext. 4342
>> Fax: 614-718-7477
>> Email: jyoung@oclc.org

Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
Received on Wednesday, 25 May 2011 15:10:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:27:44 UTC