Tom,
I think this entire post is right on the money.
DCAM provides a syntax-neutral language (which needs clarification) for
describing a data model of the 'closed world' of a domain. It's design
benefits from its primary context of providing a way of expressing a domain
model in a DCAP. It also benefits from the neutrality of its attempt to
describe broad concepts that encompass classes of 'things' like datasets
that are collections of records that are themselves collections of
statements that describe a collection of resources.
As Dan, Corey, and Antoine have pointed out there's an opportunity here to
provide a path for practitioners who increasingly have to be able to
describe and express metadata in a syntactically rich environment that
encompasses DDL, RDF, NOSQL, XML, JSON and others. A path composed not just
of vague best practices but actionable concepts that fills some of the
conceptual gaps that are barriers to effective organizational
implementation of things like distribution and aggregation of LOD as RDF,
or an enterprise data model that can effectively encompass NOSQL
document/data models.
We can learn from OWL/RDFS and our collective experience without _being_
OWL/RDFS.
Jon,
who is sitting on a beach in Florida dismayed that the beach bar has
excellent wi-fi that appears to reach out to sea
On Sunday, March 4, 2012, Thomas Baker <[log in to unmask]> wrote:
> 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]>
>
--
Jon
I check email just a couple of times daily; to reach me sooner, click here:
http://awayfind.com/jonphipps
