Re: Library data diagram

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