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

Re: Recommendations: specificity

From: Richard Light <richard@light.demon.co.uk>
Date: Tue, 29 Mar 2011 16:26:34 +0100
Message-ID: <kqt7$a5qofkNFwZP@light.demon.co.uk>
To: Karen Coyle <kcoyle@kcoyle.net>
Cc: public-lld <public-lld@w3.org>
In message <20110329064935.11765pg8pfiypv1r@kcoyle.net>, Karen Coyle 
<kcoyle@kcoyle.net> writes
>Our recommendations so far are pretty broad in nature, and I'm 
>wondering if we can get more specific. It seems to me that specific 
>recommendations are more likely to be realized. At the same time, 
>there are things we can't be specific about because we don't know the 
>answer.
>
>Here's the deduplication recommendation as an example:
>
>Analysis for the transformation of current library data to LLD
>
>    * 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. We need "design patterns" that can be reliably found in LLD, if 
large-scale searching of these resources is to be feasible.

The predicates will, presumably, simply be a new expression of 
relationships which are already well-understood in existing cataloguing 
practice. However, it is essential that these are defined centrally, 
rather than being re-invented (with different URLs) by each LLD 
publisher.

The precedent of dbpedia might give the impression that all RDF will be 
simple triples - however experience with e.g. MADS/RDF and the CIDOC CRM 
makes it clear that we need more richly-structured RDF to say the things 
we want to say.  (Arguably it wouldn't do dbpedia any harm either.)

With structural complexity comes the need for structural consistency.

>          o From text to data

i.e. from strings to URLs. As we were discussing yesterday, this is a 
general issue for pretty much everyone who is trying to convert existing 
data sources to LD - it is certainly equally true for museums and 
archives as it is for libraries.

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.

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 can be achieved by writing "URL-ifiers" to convert well-curated 
string values to URLs, such as I have done in a primitive way for place 
name strings:

http://light.demon.co.uk/wordpress/?p=54

However, the adoption of "standard" URLs requires there to be a 
"standard" resource from which to pick them.  I think that the whole 
community could usefully get together and consider how we could create 
standard resources for:

  - all people
  - all events in history
  - all dates and periods

(One for the LOD-LAM Summit, perhaps?)

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.)

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
Received on Tuesday, 29 March 2011 15:27:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 29 March 2011 15:27:49 GMT