Tom,

I think some of the confusion could evaporate if the (current)
RDFS-limited paradigms were upgraded to OWL. I'll try to highlight where
that might be possible below:

> 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,

Whereas RDFS allows properties to be either literals or entities, OWL
makes a clear distinction:

owl:DatatypeProperty (the range must be a literal)
owl:ObjectProperty (the range must be an entity)

I doubt that I would have ever grok'd RDF without this clear
distinction.

>         -- Classes,
>         -- RDF Datatypes (aka Syntax Encoding Schemes)

I've given up on custom datatypes because general purpose tools don't
recognize them. I've accepted the fact that XSD datatyptes (and
rdf(s?):PlainLiteral) are generally good enough. When the urge is
overwhelming, I declare new classes and change the property from
owl:DatatypeProperty to owl:ObjectProperty to correspond.

>         -- Vocabulary Encoding Schemes (no different from SKOS Concept
> Schemes?).

Sounds good to me.

> 
>         These are open-world semantic concepts.
> 
>     The (current) DCAM Description Set Model [1] adds the following:
> 
>         -- constructs for bounded Description Sets and Descriptions

Sounds like a graph to me. One model-neutral form of graph boundary is a
Concise Bounded Description (CBD) <http://www.w3.org/Submission/CBD/>.
Another possible natural boundary might be CBD + skos:prefLabel. Beyond
that, it seems like we're all doomed to model-specific boundaries, which
are going to be extremely difficult to agree on. For example, one
boundary might be a graph where every ounce of MARC XML juice has been
squeezed out into an ontological model. Unfortunately, MARC XML doesn't
provide a definitive place to store Linked Data identifiers. This gets
back to my practical argument of using OWL to *describe* graph
boundaries rather than *prescribe* them.

> 
>         -- 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

Sounds like owl:DatatypeProperty with some kind of constraint on the
value vocabulary.

> 
>            o  Non-Literal Value Surrogate: a set of information
> expressible
>               as multiple RDF statements (e.g., X dcam:memberOf
> <someVES>)

I'm not sure I understand the use cases, but it sounds similar to
rdfs:parseType="Collection", skos:inScheme, an inverse of foaf:member,
or something similar.

> 
>            These property-value pairs are referred to -- very
> confusingly, I
>            believe -- as DCAM "Statements".
> 
>         These are closed-world syntactic constructs -- "slots" for
> holding data.

My sense is that the days of closed-world assumptions are coming to an
end. They seem to be grounded in our past experience of relational
databases and XML Schemas. The advent of Hadoop MapReduce and HBase make
open-world assumptions a realistic alternative.

Sorry, I need to stop here.

Jeff

> 
>     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]>