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/

--
Tom Baker <[log in to unmask]>