On Tue, Feb 28, 2012 at 01:16:48PM -0800, Karen Coyle wrote:
> I developed those few 'design patterns' while working on the DCAP
> document, not DCAM. I would expect that there would be a progression
> from DCAM to DCAP -- from "simple" and basic patterns to patterns
> with more complexity and application-like constraints. Maybe
> something like going from atoms to molecules to simple organisms.
I completely agree about the "progression" from DCAM to DCAP (by way
In the current "DCAM stack":
-- the vocabulary types are grounded in RDF;
-- DCAM adds names for bounded Description Sets and Descriptions, along
with some very generic patterns (Literal Value Surrogate and Non-Literal
-- DC-DSP names types of "templates" and types of "constraints"
(DescriptionSetTemplate, NonLiteralConstraint, ValueStringConstraint...);
-- Application Profiles use the DSP language to build specific templates for a
DCAM to DSP to DCAP is one way to slice the pie, but it brings (*ahem*) a high
overhead in difficult, abstract terminology. Seen in layers:
Description Set Profile - a Description Set Template specified for a specific purpose
Description Set Template - the DSP construct for templating a Description Set with constraints
Description Set - DCAM's construct for a metadata record
RDF - abstract model for the elements of DCAM
If the ultimate goal is to express an Application Profile (Description Set
Profile) in a form that is independent of concrete encoding syntaxes but that
can be instantiated (and validated) in a range of concrete encoding syntaxes,
are there other ways to slice this pie?
Many of the patterns on  -- in my reading -- point to a constraint language.
If so, does a constraint language need to be based on an abstract model the way
DSP is based on DCAM? What, then, are the requirements for DCAM?
Rather than jump straight to these abstractions, I'd like to use examples to
clarify the basic requirements.
Tom Baker <[log in to unmask]>