On Sun, Mar 04, 2012 at 04:55:25PM -0800, Karen Coyle wrote:
> I have to admit that I am sometimes a bit confused about whether we
> are talking about DCAM or DCAP in some of this discussion. Would it
> be useful to tease those apart? Or can we clearly combine them into
> a single model? (And if they are the same, why were they two
> different things before?)
That's precisely the question I was getting at earlier in this thread (on
Tuesday). Rephrasing...:
The (current) DCAM Vocabulary Model [1] is grounded in RDFS. It has:
-- Properties,
-- Classes,
-- RDF Datatypes (aka Syntax Encoding Schemes)
-- Vocabulary Encoding Schemes (no different from SKOS Concept Schemes?).
These are open-world semantic concepts.
The (current) DCAM Description Set Model [1] adds the following:
-- constructs for bounded Description Sets and Descriptions
-- constructs for two very generic patterns for descriptive information (literals,
URIs, and blanks), grouped in Property-Value pairs in which the value is either:
o Literal Value Surrogate: expressible as one RDF statement with one RDF literal
o Non-Literal Value Surrogate: a set of information expressible
as multiple RDF statements (e.g., X dcam:memberOf <someVES>)
These property-value pairs are referred to -- very confusingly, I
believe -- as DCAM "Statements".
These are closed-world syntactic constructs -- "slots" for holding data.
The (current) Description Set Profile _Constraint Language_ (DC-DSP) [2] provides
a language for building "templates" that "constrain" DCAM constructs:
-- "template" constructs:
Description Set (DCAM) -> Description Set Template (DSP)
Description (DCAM) -> Description Template (DSP)
Statement (DCAM) -> Statement Template (DSP)
-- constructs for "constraining" the templates:
Value String (DCAM) -> Value String Constraint (DSP)
I think of this as a _language_ for _templating_ metadata records based
on DCAM slots.
The (current) notion of DC Application Profile (DCAP), as described in
the Singapore Framework [3], is centered on a Description Set Profile -- i.e.,
the specification of a particular set of Templates and Constraints. For
example:
-- "This profile specifies a Description Set Template
-- ... which holds two Description Templates,
-- ... one of which describes a foaf:Person (i.e., Resource Class Constraint)
-- ... using a Statement Template
-- ... that uses the property foaf:givenname (i.e., Property Constraint)
-- ... etc ..."
I think of a particular Description Set Profile as a particular
template for manufacturing closed-world data validation schemas in
particular concrete syntaxes -- a template for making cookie cutters.
The (current) notion of a Data Format in the Singapore Framework is that of
a closed-world data validation schema in a particular concrete syntax --
one that intellectually matches a Description Set Profile, which is
expressed in the Description Set Profile Constraint Language, which in turn
is based on DCAM.
The Data Format is the cookie cutter for making instance metadata
(i.e., "records") using a particular concrete syntax -- or for testing
whether a particular cookie (i.e., "record") _matches_ the cookie
cutter.
Looking at the top layer of the Singapore Framework [3] as a sequence for
_designing_ metadata, the idea is to:
-- Figure out why something needs to be described (Functional Requirements)
-- Name the "things" that need to be described (Domain Model)
-- Decide what properties, with what constraints, are needed for describing
those things (Description Set Profile) -- a template for a Data Format.
-- Create a cookie cutter (Data Format) for creating instance Records.
In the Singapore Framework, DCAM, RDFS, FRBR, Dublin Core and other RDF
vocabularies, and DCAM-in-XML or DCAM-in-Microdata guidelines provide the
support for this process -- they are "one layer below" the process outlined
above.
Perhaps there are better analogies than Cookie Cutters, such as patterns for
making dresses... or microprocessors. The layers of terminology ("template",
"profile"...) make it hard to tell this story clearly. And I do wonder whether
it is necessary to make these particular distinctions, or if there are simpler
ways to slice the pie. This is, I think, the question that Karen is also
asking.
Tom
[1] http://dublincore.org/documents/abstract-model/
[2] http://dublincore.org/documents/dc-dsp/
[3] http://dublincore.org/documents/singapore-framework/
--
Tom Baker <[log in to unmask]>
