Tom, all ...
I really like this initial stab at a general message, and my sense is that the use of the word ‘slots’ will resonate with folks. At least this is what I think at the moment, and it made the description easy to understand for me. This
is what is needed in the user-facing documentation and can reach beyond those immersed in DCAM..and not scare those who are new to this information.
Two brief comments --
~ In sentence one, I wanted to say “connected” slots, but I’m not sure it’s necessary. The indication of a ‘defined structure’ at the end can stand for this. I’m just thinking that is it the linking (connecting) of slots that is key.
~ Perhaps a given, but I think it would be good to list a few examples beyond book. My bias perhaps, but could we list things like a dataset, and image, and I would like to list person and event? (Do ‘Things’ like person or event
cause a problem? They may be seen as unorthodox in DCAM… I’m not sure, or in conflict w/ FRBR?)
Best wishes, jane
-----Original Message-----
From: DCMI Architecture Forum [mailto:[log in to unmask]] On Behalf Of Thomas Baker
Sent: Wednesday, February 15, 2012 12:05 AM
To: [log in to unmask]
Subject: Re: DCAM - where we stand
On Tue, Feb 14, 2012 at 05:25:17PM -0500, Tom Baker wrote:
> And there was some support for the idea that a clear "punchline" for
> DCAM, along the lines of the one-liner summarizing SKOS in plain
> language, would be helpful.
A bit longer than the one-liner for SKOS, but here's my stab at a "general message" for DCAM:
Seen as data artifacts, Metadata Records consist of slots holding
information items in a defined structure. A Metadata Record may describe a
single Thing of interest (such as a Book) or a cluster of closely related
Things (such as a Book and its Author). More abstractly, a Metadata Record
may be seen as a Description Set encompassing just one Description (i.e.,
about the Book) or multiple Descriptions (about both the Book and the
Author).
A Description consists of one or more Statements about the Thing Described
(e.g., stating the Name and Birthdate of an Author). The Thing Described
by a Description may be identified using a URI. A Statement about the
Thing Described has one slot for an Attribute (Property) and one slot for a
Value. Attribute slots are filled with names of attributes (properties);
in DCAM, attributes are "named" using URIs. Value slots are filled with
Value Strings, URIs, or blank Value Placeholders. A Value String may be
stated as belonging to a named set of strings (known as a Syntax Encoding
Scheme). A Value URI may be stated as belonging to a named set of URIs
(known as a Vocabulary Encoding Scheme). In practice, Statements may be
viewed in the context of Statement Sets. Statement Sets may follow common
patterns.
The Dublin Core Abstract Model (DCAM) provides a language for representing
the structure of specific Metadata Records -- put more abstractly, to
specify a Description Set Profile -- in a form that is independent of
particular Concrete Encoding Technologies such as XML Schema, RDF/XML,
RelaxNG, relational databases, Schematron, or JSON.
In order to provide compatibility with Semantic Web and Linked Data
applications, however, DCAM is fully aligned with the Model and Abstract
Syntax of RDF. (Note that the RDF abstract model is the basis for -- thus
distinct from -- concrete RDF encoding technologies such as RDF/XML,
N-Triples, and Turtle.) Knowledge of RDF is not a prerequisite for
understanding DCAM on an informal level.
DCAM provides a language for expressing common patterns of Statements --
patterns that may be partially or fully encoded using specific Concrete
Encoding Technologies. Indeed, some readers may find the example patterns
used in designing DCAM more accessible and useful, as models and templates
for implementation, than the formal specification of DCAM itself.
Details aside, this text illustrates the sort of high-level description I think we would need to have as an explanation both to our intended audience -- and to guide ourselves in the design phase. I'm not sure whether the mixing of
references to syntax ("slots", "Value URI") and semantics ("Thing Described") in this draft is a bug -- or a feature. I also wonder how DCAM can close the gap to expressing the constraints of real application profiles without introducing DC-DSP-like notions
such as "templates" and "constraints" [1].
For discussion...
Tom
[1] http://dublincore.org/documents/dc-dsp/
--