Hi Michael,

Thank you for picking up on the very interesting discussion
of Provenance and DCAM that we had in The Hague!

On Wed, Nov 16, 2011 at 09:59:39AM -0500, Michael Panzer wrote:
> as many of you will know, the Task Group for Metadata Provenance has
> been working on an AP for capturing the provenance of metadata in an
> interoperable way. While working on the domain model, it became clear to
> us that describing the provenance of metadata can (and probably should
> be) seen as a function of the metadata framework itself (i.e., Dublin
> Core/ DCAM) rather than just as another AP.
> 
> Instead of dealing with metadata provenance as just another type of
> metadata, consisting of a mix of Dublin Core terms and elements from
> other vocabularies, we believe it to be more useful to model such data
> as "2nd order metadata," the construction rules of which have to be part
> of the metadata framework itself.
> 
> This implies, however, that our approach, as illustrated by the
> DC-Provenance domain model
> (http://wiki.bib.uni-mannheim.de/dc-provenance/doku.php?id=domain_model
> <http://wiki.bib.uni-mannheim.de/dc-provenance/doku.php?id=domain_model>
> ), is dependent on DCAM "Description Set" being addressable as a
> first-class object, which it is not at the moment (as "Description Set"
> is not defined as an entity in the http://purl.org/dc/dcam/
> <http://purl.org/dc/dcam/>  namespace). 

I'm wondering if declaring DescriptionSet as a class should perhaps be the next
step.  A lightbulb went on for me when Kai said in his presentation that, in
his opinion, the notion of "description set" is easier to explain to people
than the notion of "named graph".

Note that Mikael pencilled in a putative class for DescriptionTemplate (along
with classes and properties other DSP entities) in the non-existent namespace
http://purl.org/dc/dsp/ -- an interesting idea not further discussed in his
working draft [1].

If DescriptionSet is a class, then AnnotationSet could be a sub-class.  I do
not have a strong opinion one way or the other as to whether AnnotationSet 
should be in DCAM itself.  I'd like to address that question in the context
of the broader question about how to revise DCAM.  There is clear support for
the idea of revising DCAM but a range of opinions on what that revision
should mean.

I don't believe there is any disagreement -- at least among the people who
participated in the breakout session in The Hague -- that DCAM should be
consistent with RDF.  However, there is disagreement as to whether a revised
DCAM should be based directly on RDF as proposed by Mikael in 2009, or whether
it should be seen as model on a higher level of abstraction, the RDF expression
of which could be seen as an "implementation" of the model.  Either way, I'd
really like to see a DCAM that is more concise and reader-friendly than the
DCAM we have now.

I think there is merit in both the RDF-based and higher-level views of DCAM,
but either way, I think it is important to get some consensus on the purpose
of DCAM and the requirements it meets before taking a decision on whether to
include AnnotationSet as a first-class object.

As part of this discussion, I think it will be very important to review the
requirements revealed by the experience of Gordon's ISBD Task Group.  My
impression was that Gordon's requirements related more to the constraint
language -- at present, we only have DSP, and that is only a draft -- and to
its expressivity with regard to conditions such as "mandatory if applicable",
but it would be good to have them on the table for the discussion of DCAM
itself.

It would be good if we could have a teleconference about DCAM.  In a follow-up
message, I will post a Doodle poll for a conference sometime in the three weeks
between 5 and 23 December.

[1] http://dublincore.org/documents/dc-dsp/#sect-8

>                                          An outline of our approach can
> be found here
> (http://dcevents.dublincore.org/index.php/IntConf/dc-2011/paper/view/44/
> 3). Essentially, we are extending DCAM by reapplying it to itself,
> therefore adding the possibility for describing a DCAM metadata resource
> (a "Description Set") with Annotation Sets (defined at a subclass of
> Description Set). This creates a second level of description for DCAM,
> designed to provide a "box" for general metadata about the product of
> DCAM itself.

I think I see what you are driving at, though I'm not sure I understand
exactly what you mean by "product of DCAM".

To my mind, adding the notion of AnnotationSet means introducing
a special type of metadata that serves special purposes.  The "cost"
of doing so, arguably, is that it makes the model more elaborate.
I think you are agreeing that an Annotation Set _could_ simply be seen,
recursively, as just another Description Set.  But making the model
that tiny bit more elaborate might also be seen as a "benefit" if it
helpfully highlights the notion of provenance.

Parenthetically: as the RDF Working Group progresses towards a standardized
concept (or concepts) of Named Graphs, I wonder what sort requirements and
applications might emerge for specific types of descriptions such as annotation
set.  Conceptualizing the FRBR entities as sub-graphs, for example, could imply
the notion of a WorkDescription or an ExpressionDescription.

> Other metadata frameworks have been dealing with similar issues of
> creating a space to hold "metametadata" as part of their model; in case
> of RDF, by making named graphs (their version of Description Sets) part
> of the next version of RDF, so graphs (i.e., sets of metadata) can
> easily be addressed as subjects of statements. 

I think I missed the part of the discussion in The Hague where you
looked at the three types of named graphs being discussed in the RDF
WG in terms of the DCAM Description Set...?

> I think our main question to the Architecture Forum is: Is it desirable
> to incorporate our extension into DCAM itself, or should it rather be
> part of the DC-Provenance Application Profile suite of documentation? I
> think our group is strongly leaning towards the former, and would be
> delighted to work with the Architecture Forum to pursue this avenue
> (i.e., a revision of DCAM) further.

I agree and think we should meet on a call sometime in December to 
discuss this further!

Tom

-- 
Tom Baker <[log in to unmask]>