W3C home > Mailing lists > Public > public-lld@w3.org > September 2010

Re: Library data diagram

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Thu, 02 Sep 2010 09:53:24 -0700
Message-ID: <20100902095324.8qenzyb5s00go40c@kcoyle.net>
To: "gordon@gordondunsire.com" <gordon@gordondunsire.com>
Cc: Emmanuelle Bermes <manue.fig@gmail.com>, public-lld@w3.org, Thomas Baker <tbaker@tbaker.de>
Thank you, Gordon. Yes, the ICP does describe the primary goals of  
library data, e.g.

4.1.1. to find a single resource
4.1.2. to find sets of resources representing
all resources belonging to the same work
all resources embodying the same expression
all resources exemplifying the same manifestation
all resources associated with a given person, family, or corporate body
all resources on a given subject

I'm wondering if these requirements are sufficient for our purposes or  
if they need some interpretation in order to become guidance for LLD.  
In fact, perhaps this document (given that it is quite succinct --  
only 15 pages) would be a good one to discuss at the f2f as a way of  
understanding library data requirements in general, as a lead-in to  
LLD requirements.

I'm also wondering if we couldn't use a few of these as use cases. For  
example, how does one define a "controlled access point" in a linked  
data environment? Is the use of a URI enough, or is more needed? Does  
the definition of Manifestation and the means to identify it change in  
an environment where anything can link to anything? (I'm not expecting  
us to answer these questions -- I think that surfacing the relevant  
questions would be quite enough.)

kc

Quoting "gordon@gordondunsire.com" <gordon@gordondunsire.com>:

> Emmanuelle, Karen and others
>  
> I think we do have a good set of stated functional requirements that are
> generally applicable to library catalogues and metadata: the Statement of
> international cataloguing principles (ICP) developed by the IFLA Cataloguing
> Section and IFLA Meetings of Experts on an International Cataloguing  
>  Code. It is
> available in English at:
>  
> http://www.ifla.org/files/cataloguing/icp/icp_2009-en.pdf
>  
> Translations into 24 other languages are available at:
>  
> http://www.ifla.org/en/publications/statement-of-international-cataloguing-principles
>  
> ICP is an update of the Paris principles from the early 1960s, which in turn
> were based on Cutter and others. ICP takes into account FRBR, FRAD, etc. and
> covers the range of things mentioned by Emmanuelle. ICP is "intended to guide
> the development of cataloguing codes" and the principles are thus   
> quite general,
> but I guess there's sufficient detail to inform discussions on the   
> DCMI AP and
> Singapore Framework.
>  
> Cheers
>  
> Gordon
>  
>
> On 02 September 2010 at 10:08 Emmanuelle Bermes <manue.fig@gmail.com> wrote:
>
>> >
>> >
>> >  If this is done, then the metadata creation workflow in
>> >> libraries can be seen as fitting both the Singapore Framework
>> >> view and its implied workflow (which starts with Functional
>> >> Requirements)
>> >>
>> >
>> > and there is the rub. We still do not have a good set of stated functional
>> > requirements, at least that I know of. (The last good set that I've
>> > encountered are Cutter's functional requirements from 1878 --   
>> excellent, but
>> > perhaps needing some revision, especially some addition of detail.) As I
>> > recall from my long ago courses in cataloging at library school, a good
>> > instructor pulls these concepts out of the rules and uses them   
>> for teaching.
>> > But I haven't seen an actual document that would summarize the functional
>> > requirements of RDA.
>> >
>>
>> I thought that a lot of the functional requirement were actually common with
>> FRBR and FRAD : they are broad, but they do exist. Am I mistaken ? Or do we
>> need to declare something more specific ?
>>
>> Then, we would need to add things like requirements for authorized access
>> point, variant access points, statements, core elements, and other such
>> basic concepts underlying RDA.
>>
>> Another lightening talk for the joint meeting in DC2010 ? If we don't start
>> with that kind of stuff, it will be difficult to define what are the
>> community needs in terms of patterns definition.
>>
>> Emmanuelle
>>
>>
>> >
>> > So that's the library landscape, as I see it, compared to the SF diagram.
>> > I'm sure I've glossed over some important points and perhaps   
>> mangled others.
>> > However, any work on linked data must begin at this point and work to move
>> > things forward, so understanding this "state" gives us common   
>> ground for our
>> > work.
>> >
>> > I do hope others will contribute their knowledge in this area. I'm sure my
>> > own knowledge is incomplete.
>> >
>> > kc
>> >
>> >
>> > Quoting Thomas Baker <tbaker@tbaker.de>:
>> >
>> >  Thank you, Emmanuelle, for drawing up the comparative
>> >> diagrams [1] and thank you, Karen, for getting the ball
>> >> rolling on discussion.
>> >>
>> >> A comment specifically on Singapore Framework [2]...
>> >>
>> >> On Tue, Aug 31, 2010 at 08:38:36PM -0700, Karen Coyle wrote:
>> >>
>> >>> The Singapore Framework places guidance rules outside of the flow of
>> >>> vocabulary and DCAP development. This makes me think that in SF the
>> >>> guidance rules are developed and applied after the other steps toward
>> >>> an application profile have taken place.
>> >>>
>> >>
>> >> As I see it, the SF diagram is intended to show how the
>> >> components of an "application profile" relate to each other
>> >> and to underlying foundational standards (RDF).
>> >>
>> >> The diagram does also suggest a workflow, and I too like to
>> >> present it this way -- starting with Functional Requirements,
>> >> through defining a Domain Model, specifying a Description Set
>> >> Profile and, finally, creator a Data Format, with the designer
>> >> "dipping down" one level to create new or cite existing domain
>> >> models and vocabularies.  And as a rough approximation, this
>> >> seems like a reasonable way to proceed as long as it is not
>> >> applied too mechanically.  In the end, though, SF is meant
>> >> to depict less a specific sequence of tasks than a picture of
>> >> how things relate.
>> >>
>> >>                                          This is accurate in terms of
>> >>> Dublin Core metadata, which was developed initially without actual
>> >>> guidance rules.
>> >>>
>> >>> In Emmanuelle's diagram of library metadata, the guidance rules appear
>> >>> to precede the vocabulary. This is accurate in terms of library
>> >>> metadata, in which the vocabularies arise from the guidance rules.
>> >>>
>> >>> These two models, DC and libraries, seem to me to be the extremes of
>> >>> the development continuum. In libraries the guidance rules are the
>> >>> most important aspect of the metadata creation activity, and in Dublin
>> >>> Core they can almost be considered unnecessary.
>> >>>
>> >>
>> >> If for libraries, guidance rules are the point of departure for
>> >> metadata design, then "support for guidance rules" would quite
>> >> simply need to be defined as a key functional requirement.
>> >>
>> >> If this is done, then the metadata creation workflow in
>> >> libraries can be seen as fitting both the Singapore Framework
>> >> view and its implied workflow (which starts with Functional
>> >> Requirements) -- only that, in this case, the functional
>> >> requirements may be unusually heavy on existing guidance
>> >> rules...
>> >>
>> >> Tom
>> >>
>> >> [1] http://www.w3.org/2005/Incubator/lld/wiki/File:LayeredModelV3.pdf
>> >> [2] http://dublincore.org/documents/singapore-framework/
>> >>
>> >> --
>> >> Tom Baker <tbaker@tbaker.de>
>> >>
>> >>
>> >>
>> >
>> >
>> > --
>> > Karen Coyle
>> > kcoyle@kcoyle.net http://kcoyle.net
>> > ph: 1-510-540-7596
>> > m: 1-510-435-8234
>> > skype: kcoylenet
>> >
>> >
>> >



-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
Received on Thursday, 2 September 2010 16:54:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 2 September 2010 16:54:02 GMT