Print

Print


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/

 

--

Tom Baker <[log in to unmask]>