Re: Library data diagram

Karen
 

On 03 September 2010 at 18:16 Karen Coyle <kcoyle@kcoyle.net> wrote:

> Gordon:
>
>
>   In other words, Bob needs to
> > find and identify "all resources embodying the same expression".
> >  
> > However, that's essentially a use case for the ICP itself, and translating
> > it
> > into something relevant to linked-data (other than a generic observation
> > that
> > linked-data helps) may be difficult.
>
> Yes, I ran into the same thing when I tried thinking it through. I 
> think linked data offers an expansion of the ICP goals. Library 
> catalogs may be able to allow you to identify all available resources 
> for the same expression, but LLD will be able to allow users to 
> navigate through different translations, through transformations into 
> different formats and media, and hopefully even to follow paths of 
> "cites/cited by" to explore the transfer of knowledge through time. 
> Just as the web is moving from a web of documents to a web of data, 
> library catalogs could move from contiguous records to actual 
> connections based on the information about the resources. I think our 
> definitions of functional requirements have been limited by our vision 
> of our data.
>The combined FR model with RDA layered on top should be rich enough to support
>these kinds of navigation through bibliographic space ("cites/cited by" is not
>specifically part of RDA, I think, but I expect it to be a sub-type of the "has
>subject/is subject of" property that is likely to be part of the FR model). All
>that is required to implement such services is a recasting of current systems
>and metadata to handle FRBR-ised records - but they remain records (the Work
>record, the Expression record, etc.). This does not require LLD, so I think we
>are still finding it difficult to tease out the "why LLD is essential, rather
>than desirable" angle. The drivers I'm thinking of at the moment are economic
>(1. FR reduces duplication of metadata, and therefore effort/cost, by splitting
>the current unit of process from one bibliographic record into three or four
>(WEM/I); LLD goes much further by focussing on the smallest possible unit of
>process, the metadata statement/triple - 2. LLD allows effective
>interoperability between metadata generated by professionals/cataloguers,
>amateurs/users, and machines) and ideological (most librarians operate in open,
>communitarian environments, which can be significantly enriched by the
>open/global focus of LLD).
 
So I think we should be developing use cases that have library funders as actors
- and we need to challenge current thinking in some quarters that catalogue
records are a business asset that are "owned" by someone (it's not clear who has
the intellectual property rights to a record that was created in one library,
contributed to a shared cataloguing system, amended by a second library, copied
by a third library, etc.) and therefore cannot be "free". There are also
concerns about cost-recovery for the maintenance, etc. of metadata, content
vocabularies, models, standards, etc. which we must address.

> >  
>   For
> > example, the property "is based on (name)" has domain CAP and range   
> > Name, so we
> > can infer from an instance triple "X is based on (name) Y" that X is 
> >  a CAP. Note
> > that X and Y may have the same label (that is, the Name Y does not   
> > require any
> > addition to its label to make it a CAP); the distinction is made on the
> > assumption that some Agency (another FRAD class) has applied a specific Rule
> > (another FRAD class) to the Name in order to generate the CAP.
>
> I look forward to the FRAD documentation becoming available, but as it 
> is not at the moment it's very hard for any of us outside of the 
> immediate FRAD committee to make sense of it. I am concerned about the 
> use of "name" in earlier versions that I saw, because it appears that 
> a display form is being used as an identifier. I hope that is not the 
> case. The use of "real" identifiers should allow us to place less 
> emphasis on display forms. I have to admit that I have doubts about 
> the need for "controlled access points" in this new environment, based 
> as they are on the construction of specific text strings that function 
> as identifiers. But this is based on my reading of RDA, not FRAD.The FRBR
> Review Group is also frustrated and concerned at the delay in making FRAD
> available as a free download from the IFLA website. We are hoping to resolve
> the problem in the near future, and I'll email the LLDXG as soon as it
> happens.
 
I don't think we can avoid using ambiguous terms for human readable labels of
entities/properties/elements/whatever. The main thing is the definition, and how
developers use properties to build services. The "real" identifiers are, I
think, URIs (not designed for human consumption), so I suspect that display
forms will become even more important, especially as the number of things with
similar "names" (agents, products, concepts, etc.) increases in the LLD universe
(i.e. the Semantic Web). FRAD has separate classes for Name and Identifier - you
can see the differences in definition (and scope note) in the draft RDF
representations in the Registry. Both can be the basis of a CAP (hence the
qualifier in the label "is based on (name)"). CAPs function as "identifiers" for
humans; a CAP based on an individual frad:Identifier like an ISBN functions as a
shorthand/citation form for, say, a CAP based on a same-as individual frad:Name
like the title of an individual frbrer:Work.

>
> However, in general I think that we need to make the transition from 
> "things" to "relationships." As an example, most catalogers would 
> consider an author to be a thing, rather than a person with a 
> relationship to a resource. It's a more of a viewpoint change than an 
> actual change in how decisions are made when creating the library 
> metadata.I totally agree!

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