All
I think these patterns are a good starter set, and suggest we add the more
complex patterns I suggested earlier [1].
These range from overlaps with Karen's set through tests of additional
specifics in SoDC-CL such as cardinality, to the mega-patterns of concrete
schema interoperability.
I'm happy to try and translate these into the formats used in Karen's
patterns (including examples).
btw, I wish I'd know about Alisatair's stuff on the architecture wiki
before now - it's a great articulation of issues we've been discussing in
the ISBD/XML Study Group, FRBR Review Group, and Joint Steering Committee
for Development of RDA. But the language/terminology mis-match between
abstract modellers and librarians certainly prevented me from finding it
via Google.
Cheers
Gordon
[1]
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1202&L=DC-ARCHITECTURE&P=6405
On 22 February 2012 at 02:46 Thomas Baker <[log in to unmask]> wrote:
> In 2008, Karen started to enumerate some common design patterns. We have
> provisionally concluded that a revised DCAM would need to be be based on,
and
> illustrated with, examples. Here -- minus the DSP angle-bracket examples
-- is
> the starter set of patterns. They are similar in nature to the examples
that
> Alistair penciled into his draft.
>
> Can we take this as a start, or does anyone want to propose a different
type of
> examples (or patterns)? As Antoine has suggested, the effort of just
trying it
> might be less than the effort of discussing it in the abstract...
>
> Tom
>
> ----------------------------------------------------------------------
> http://dublincore.org/dcmirdataskgroup/apDesigns
>
> Some Application Profile Design Patterns
> These design patterns are based on the Dublin Core Description
Set
> Profile (DSP). The DSP structure is a single description set that
> contains one or more descriptions, each of which contains one or
more
> metadata statements. Both the description and the metadata
statements
> can define constraints on usage.
>
> Statement: A Simple String
> The simplest metadata statement describes a property that
takes a
> simple string value ("literal"), with no constraints.
> [... example ...]
>
> Mandatory and Repeatable
> Both description templates and statement templates can be
coded as
> mandatory/optional and repeatable/not repeatable. This is
done
> using the values "minimum" and "maximum". The most commonly
used
> values are:
> [... example values ...]
>
> The following code defines a property ("title") that is
required
> and not repeatable:
> [... example ...]
>
> Using Controlled Lists
> One way to assure consistency of metadata use is to require
that
> values be taken from a controlled list. Controlled lists can
be
> short ("yes" "no" "maybe") or they can be long (such as the
Library
> of Congress Subject Headings, which number about 250,000).
>
> To define a property as taking a member of a controlled list
as its
> value using the terms of the DC Application Profile, the
controlled
> list is called a "Vocabulary Encoding Scheme" and the list
itself
> is represented with its identifier, a URI. Use of a list can
be
> mandatory or optional.
>
> This code illustrates a "subject" property that optionally
can use
> terms from the LC Subject Heading list.
> [... example ...]
>
> This code shows a subject property that requires the use of a
term
> from the LCSH list:
> [... example ...]
>
> If you have a short list that you wish to embed in the DSP
you can
> do that using the "LiteralOption". Each term is listed, and
values
> must be taken from the list:
> [... example ...]
>
> You can support multiple languages with the LiteralOption by
> including the XML "lang" attribute:
> [... example ...]
>
> --
> Tom Baker <[log in to unmask]>
|