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]<mailto:[log in to unmask]>>