2008-06-02 DC-ARCH telecon - meeting notes

DC-HTML

   Mikael: Spec is done; only the compatibility note remains
   (http://dublincore.org/architecturewiki/DCAMDCHTML).

   Pete: DC-HTML has mappings to DC-TEXT - Ivan wanted RDF
   outputs as well.  This is not hard to do.

   Mikael: Am prepared to review text as soon as available.
   Good to have something before summer.  For compatibility
   note, go through comment?

   Tom: Do not think we necessarily need official four-week comment
   period for this.  Enough to put out onto DC-ARCH for awhile.

   Mikael: Let's do ASAP, then post to DC-ARCH list for a week
   or so, have another DC-ARCH telecon, then publish.

   Pete: If we do compatibility note first, can aim for
   Monday, 9 June.  For specification itself, by Monday,
   16 June.

   Mikael: Let's try to schedule a final call before end
   of June.  Have ready for publication by end of month,
   publish at next opportunity.

DSP

   Mikael: While I would love to move it to Proposed
   Recommendation, too many things are in flux.  Discussion
   of AP documentation, and DC-HTML/DC-XML still moving.
   These are more important to finalize than DSP itself.
   DSP would also benefit from more implementation experience
   before finalizing.

Singapore Framework

   Mikael: Has not gone through a process; it is not really an ARCH
   document.  What is the process?

   Tom: Suggest we discuss on ARCH for now (public list)
   and suggest we approach SF issues by looking first at
   Interoperability Levels.

   Pete: Singapore Framework is fairly clear as a
   self-contained thing that depends on DCAM.  Some factors
   introduced there also apply at Level 2 or even Level 1.
   Given that the SF (as a self-contained thing depending on
   DCAM) is now clear, we would risk overloading the concept
   "application profile" if we try to generalize too much.
   Would not wish to lose the notion of a bounded DCAP.
   Whether we call that bounded thing "Singapore Framework"
   is another issue.

   Mikael: You suggest we fold interoperability levels into
   Singapore Framework?

   Pete: If we want overarching document, then relationship
   between components you might create at each level and the
   nature of those levels - a close relationship.  But as
   currently defined, the SF doc is a framework explicitly for
   "level 3" (DCAM) profiles.  Becomes much more complex if
   we try to make the concept encompass all levels.

   Anyway, we need a model providing DCAM-plus-DCAP.
   Whether we call is "Singapore Framework" is another thing.

   Mikael: Without DCAM specifically, what remains would be
   useful guidelines for developing APs, but those guidelines
   would be equally applicable to developing an RDF vocabulary
   as opposed to application profiles specifically.  Danger
   that it would become so general as to be meaningless -
   i.e., if we don't say what an "application profile" is.
   Alternative is to define a more flexible notion of
   application profile; but still needs to be grounded in
   some sort of formalism.  Functional requirements, domain
   model - such things are in fact applicable to anything.
   But Singapore Framework is a user of such good-practice
   principles, not the source.

   Pete: Not even sure it is possible to address broader sphere with
   an all-encompassing notion of application profile, meaningfully.

   Mikael: Could encompass something like an RDFa application,
   for example.  The question is how to define in such a way
   as to avoid including applications that are completely
   _incompatible_ with DCAM notions.

   Mikael: Way forward: keep discussion going on DCAP and
   Interoperability Levels documents.

DC-XML-Full format

   Mikael: Relatively advanced stage, and people are
   requesting an XML format.  Also believe this serves
   to highlight the design of DCAM.  What next steps?
   Move forward as Proposed Recommendation, see what public
   comment brings?

   Will need to discuss DC-XML-Min in Berlin - will need
   to gather interested people and find an editor. I am
   willing to drive the discussion, gather requirements,
   but someone would need to step forward to develop this.
   Not sure we have all the requirements in place for this.
   Not clear what a "subset of DCAM" would mean here.
   Let's postpone for Berlin.

   Pete: As far as I can recall, the only outstanding issues
   had to do with verbosity, commonality with DSP syntax,
   whether it supports abbreviated form of URIs (CURIEs) or
   something application-specific ("namespace declaration"
   in the last version).  Only two issues.  When we last
   discussed we were leaning to "only full URI" approach.

   Mikael: Supporting different kinds of identifiers would
   complicate the spec.  People would use something else
   entirely if they had special needs.  Making it easy to
   parse is key.  By analogy, DC-TEXT doesn't try to be very
   intelligent - DC-XML is analogous to that.  Let's simplify
   the proposal as much as possible.

   Pete: There is a draft version that does that, but
   schemas and XSLT that go with it are not yet ready.
   For Proposed Recommendation, would need to be posted as
   a static doc. Start of August?

   Mikael: For DC-2008 I have proposed two ARCH meetings
   (two slots).  This discussion confirms we need this.
   We need one larger meeting where all the things regarding
   APs, InteropLevels, etc, are discussed.  Bring in relevant
   task-group leaders.  Have open discussion.  That is the
   only forum where that discussion will happen.  Should post
   an invitation to the relevant working groups, eventually -
   once we have text describing that meeting in place.

   Other meeting: technical details of DSP, etc.  Tried to
   avoid conflict between open forum and groups developing APs.

--
Dr. Thomas Baker <[log in to unmask]>
Director, Specifications and Documentation
Dublin Core Metadata Initiative