Re: Recommendations: specificity

Quoting Richard Light <richard@light.demon.co.uk>:


>>
>>   * Goal: maximize the value of library data through use and re-use
>>         o From records to statements
>
> This requires there to be agreement on both the predicates that are  
> used, and the general structural pattern of library data when  
> expressed as RDF.

I think we need some "best practices", but there will definitely be  
more than one -- LD finally gives us the opportunity to have different  
but interoperable data for all of the specialist communities (music,  
maps, archives, museums) that have needs outside of the "book on the  
shelf library" norm. We have definitely talked about the need for best  
practices in the WG, and I will now add that to the recommendations,  
if it isn't already there. Emphasizing the plurality and attention to  
interoperability. We've also talked about these as being Application  
Profiles, which is part of the *how* aspect.


> We need "design patterns" that can be reliably found in LLD, if  
> large-scale searching of these resources is to be feasible.

I actually started working on some as part of the DCMI Application  
Profile work, but didn't get very far -- mainly because of problems I  
had with DCAP, not with the concept. Unfortunately, I can't find it on  
the DC site. But this is definitely something we want to do, AND ... I  
will add it to the page.



>
> Some string data can and should stay as strings in the LD  
> manifestation: dimensions, number of pages, etc. In principle,  
> everything else _could_ become a URL.

This is an analysis that we need to do, again to add to the list. Some  
of it has to do with cataloging concepts like "transcription" that may  
need to be revisited or analyzed with LD in mind. I'm going to add it  
in the list as the "things and strings" analysis. :-)


>
> However, I think that efforts should be concentrated on getting URLs  
> into the LD which represent concepts of general interest, e.g.  
> people, places, events, dates. These nodes in the resulting RDF  
> graph will be significant points of linkage with the rest of the  
> world's Linked Data (or at least with the Cultural History bit of it).

This is something that has been bugging me for a while. We really need  
more re-usable vocabularies for common things: places, events, people,  
etc. etc. FRBR "invents" a number of these within the library metadata  
framework, but they should be linkable to a broader context. We are  
starting to get some of these in the cloud (Geonames) and there are  
some that are already standardized but not yet "cloudy" -- like ISO  
language name standards. I'd be willing to put these types of  
vocabularies as high priority for LLD and for all LD.

>  - all people
>  - all events in history
>  - all dates and periods
>
> (One for the LOD-LAM Summit, perhaps?)

Indeed!

>
> Another general point on strings and URLs is that all the standard  
> authorities used in library cataloguing should be (re-)published as  
> Linked Data. Then it becomes straightforward to convert e.g. "640"  
> to "http://dewey.info/class/640/".  (This may be less of an issue  
> than it is for museums: e.g. LCSH and Dewey are already done.)

LCSH is done, but Dewey is only available on a limited basis because  
there are contractual constraints. Aside from that, though, one of the  
issues that I see here is that many of these vocabularies are "owned"  
by single institutions and therefore we are dependent on those  
institutions to issue them in RDF. Out of some frustration about this,  
both Ross Singer and I have independently done some work on MARC  
vocabularies. And look at what has happened with FRBR, which was not  
provided by its "creator" body until many years after others had done  
so. This is not a rant against those institutions but a real problem  
that we need to deal with. Can we find a way to "communalize" more of  
these vocabularies so that they can be converted in a more agile manor?

kc


>
> Richard
>
>>         o Both the transformation of the data as well as the  
>> migration of systems
>>   * Study LLD from an information seeker's point of view
>>   * Consider LLD not just as a transformation of current library  
>> data but as leading to a new vision of future library data
>>   * Set priorities, or at least create criteria for prioritization  
>> (unique materials v. mass produced; unique data v. shared data)
>>
>> Can we be more specific than this?
>>
>> link:  
>> http://www.w3.org/2005/Incubator/lld/wiki/Draft_issues_page#Analysis_for
>> _the_transformation_of_current_library_data_to_LLD
>>
>
> -- 
> Richard Light
>



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

Received on Tuesday, 29 March 2011 17:00:41 UTC