Re: Library data diagram

On Wed, Sep 08, 2010 at 11:20:36PM -0400, Jeff Young wrote:
> though, that FIG 6 *IS* a model and thus satisfies the mold for being a
> DC application profile itself. I assume the use cases you give below
> would be extensions of this model/profile. 

I meant them only as possible constraints one might
additionally want to specify in an application profile -
as examples (and bearing in mind that in the DCAM/DSP/SF
approach, almost all such constraints are optional).

Marcia et al's proposal for a "FRBR family"-based domain
model for DCAPs addresses a fundamental component of a "DC
application profile": the "domain model" that specifies what
types of resources are being described.  However, the DCAM/DSP/SF
approach also goes a step beyond the domain model by specifying
constraints on the properties and associated values used to
describe instances of entities in that domain model.

> >     Subjects are to be taken from LCSH.
> 
> This could be implemented using xsd:restriction...
...
> >     The described resource must have a title.
> 
> This could be specified in XML Schema using...
...
> >     Titles may be in English or Spanish only.
> 
> I'd have to dig around, but I assume these constraints could be imposed
> using XML Schema somehow.

It's fine to build a solution stack on a specific syntax such
as XML schema.  I'm not questioning that idea, just saying where
I see difference to the DCAM/DSP/SF approach.

The idea behind DCAM/DSP/SF is to offer constructs and language
for expressing application profile constraints independently of
any specific syntax.  Designers of metadata are not typically
experts in the limitations of particular technologies like
XML Schema (e.g. librarians), and implementers may have good
reasons to want to implement a particular metadata design in
different or multiple syntaxes (e.g., XML Schema and RDFa).
The DCAM/DSP/SF approach of course acknowledges that
alternative implementation syntaxes are not equally expressive
of the constraints that people may want to define.

Both your approach and DCAM/DSP/SF embrace the idea that data
may be expressed in a back-end syntax such as XML Schema and
mapped to, exposed as, RDF triples.

Tom

-- 
Thomas Baker <tbaker@tbaker.de>

Received on Thursday, 9 September 2010 13:06:21 UTC