Picking up on the other thread...
On Fri, Aug 07, 2009 at 12:03:35AM +0200, Mikael Nilsson wrote:
> As for the DSP model, I've explicitly stated in recent (err...)
> Architecture Forum teleconferences that I believe the DSP model needs
> implementation experience before taking it forward.
>
> I'm very much hoping that feedback from ePrints/SWAP, RDA and Karen, and
> eventually LOM and ISO MLR will help shape an updated draft of the DSP
> model. The model as it stands is a theoretical construct, and needs
> exactly the kind of development testing that is happening right now to
> my great delight!
>
> So, to summarize (from my mostly AFK vacation): you're absolutely right,
> and I believe that's the plan...
>
> Maybe Tom can fill in from a DC perspective?
I think Karen's work on application profile designs [1] is right
on target for what needs to happen next.
As I see it, DCAM is a bridge between the Linked Data paradigm
(where everything is linked together in an unbounded graph) and
the Metadata Record paradigm more familiar to libraries,
repositories, and other data management contexts. DCAM does this
by providing the notion of a bounded "description set".
The Description Set Profile language, then, provides a link
between the "description set" and the specific types of
constraints that information designers working in the Metadata
Record tradition want to validate.
Karen's design patterns suggest a path for getting from the
notion of validatable constraints, in the abstract, to concrete
tool support -- via libraries or palettes of the most common
patterns one might draw on to automate the construction of
metadata creation and validation tools.
My instinct on this is that if the Metadata Record paradigm is
to be translated into today's increasingly Linked-Data
environment, and if records are to be designed specifically for
compatibility with Linked Data, something very much like DSP is
needed. I doubt that there is -- even theoretically -- a
"perfect" DSP model. Mikael has alluded to choices he has made,
for example in putting forward a relatively lightweight matching
algorithm in order to make DSP usable on systems that lack full
support for SPARQL.
The Description Set Profile draft is a starting point, a stake
in the ground for moving the discussion forward. In a sense,
the existence of DSP is justified by the sort of work Karen is
doing because DSP provides a concise language for expressing
thoughts like:
<?xml version="1.0" encoding="UTF-8"?>
<DescriptionSetTemplate xmlns="http://dublincore.org/xml/dc-dsp/2008/01/14" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://dublincore.org/xml/dc-dsp/2008/01/14">
<DescriptionTemplate>
<StatementTemplate type="nonliteral">
<Property>http://purl.org/dc/terms/subject/</Property>
<NonLiteralConstraint>
<VocabularyEncodingSchemeOccurrence>optional
</VocabularyEncodingSchemeOccurrence>
<VocabularyEncodingSchemeURI>http://purl.org/dc/terms/LCSH
</VocabularyEncodingSchemeURI>
</NonLiteralConstraint>
</StatementTemplate>
</DescriptionTemplate>
</DescriptionSetTemplate>
To take the next step beyond this, one would need another person
who could translate Karen's patterns, like the above, into
running code.
The ideal would be to evolve the base DSP specification, design
patterns, and running code in synch with each other. In my
experience, this happens best when there is a project team that
holds regular teleconferences. From a DCMI perspective, this is
definitely of interest, and could potentially be a priority for
the organization. Realistically, this would depend on forming a
committed team with the right mix of skills and perspectives to
move this forward.
Tom
[1] http://dublincore.org/dcmirdataskgroup/apDesigns
[2] http://dublincore.org/documents/dc-dsp/
--
Thomas Baker <[log in to unmask]>
|