Hi Rachel!

Unfortunately I did not have any possibility to answer this earlier, but
I still have some comments.

I believe formalized DCAPs are a natural extension to the DCAM work, so
the Guidelines are definitely interesting, and something for this group
to consider. It's a very difficult task for several reasons, of which
you mention a few in the draft (e.g. the LOM and ISO problems).

I do think the general approach is right, but I have a feeling that the
proposal fails to support its own usage scenarios. My comments come from
our own experience with machine-processable APs. In short, the following
issues make the proposed AP expression difficult to use in practice:

* No explicit support for multiple descriptions in one record (i.e.
hierarchical metadata).
* No one-to-one mapping to machine representations of the metadata. This
is also a general DC problem - there are several equivalent but
different RDF expressions for the same metadata. This makes the kind of
automation described in section 3 impossible.

I asked my colleague Matthias Palmér to comment (he works with those
issues but is not subscribed to this list), and his initial response is
inserted below.

That said, it would be interesting to create something very similar to
this, based more directly on the DCAM, and possibly more complete in the
above areas.

/Mikael

------------------------ cut -----------------

I start be describing shortly what we have and then continue by
describing what I think of the draft in the setting of what we would
need to be able to make use of DCAP.

In our research group (knowledge Management Research see
http://kmr.nada.kth.se) we have a project named SHAME (Standardized
Hyper Adaptible Metadata Editor, see http://kmr.nada.kth.se/shame) which
might be of interest.

In short, SHAME is a framework for editing, presenting and searching for
RDF metadata through forms. The forms are generated through the
composition of what we refer to as formlets. Hence such a compound is a
very pragmatic application profile since it describes (via the
individual formlets):

1) Which properties to use. We can specify arbitrary deep metadata
constructs not just direct properties, hence we can handle qualified
dublin Core.
2) Restrictions regarding datatypes and wheter literal should have an
language encoding.
2) Which vocabularies to use, either static list or detected from RDF
Schema.
3) Type restrictions on intermediate resources (e.g. qualified dc:date)
4) Multiplicity restrictions
5) Rendering information for the forms, including:
  a) labels and descriptions in the forms that are language controlled
  b) Grouping of metadata, think of LOM categories.

Our approach is to provide a library of formlets for the most common
standards and encourage reuse of those, when this is not enough you can
create your own formlets or simply copy and adapt formlets to your need.
We have some tools that can be of assistance:

Formulator - a tool that aids you to create new atomic or compound
formlets. 

Meditor - a generic Metadata Editor where you can edit metadata via
atomic formlets or compound formlets.

Web demo - a proof of concept web variant of meditor (can be tested from
the homepage).
 

Ok, that much for background.
In general, our interest is to generate metadata editors for complex
metadata schemas / standards such as LOM in RDF. (See the new standard
project http://ltsc.ieee.org/wg12/par1484-12-4.html with a draft
available at http://kmr.nada.kth.se/el/ims/md-lomrdf.html.) And this
cannot be done with the current DCAP since it describes only flat
metadata.

Some ideas:
^^^^^^^^^^^

Wouldn't it be nice to point from the AppProfile to the PropertyUsage
instead of the opposite? That way it would enable reuse of PropertyUsage
objects in various AppProfile objects.

What about allowing PropertyUsage objects to be listed via an rdf:Seq
from the AppProfile, allowing an order to be specified which would be
very useful for generating presentations or editors on the fly.
  
What about providing both a minimum and maximum cardinality, now you
only provide a maximum via the occurence property. I realise that this
somewhat collides with the obligation. By the way, I do not understand
why you haven't provided a default obligation vocabulary instead of just
a Obligation class. My guess that mandatory could be expressed with
minimumCardinality 1, optional with 0 which could be the default.
(By the way in the examples you have typed the instances with lower case
first letter... not recomended practice as I have learned, is it
intentional?)


The use of rdfs:label on PropertyUsage instead of dc:title on
PropertyUsage does not encourage multiple language labels. This seems
like an unnecessary hinderance to multilingual DCAP.

The statement in 6.1:
"A DCAP may be associated with one or more binding schemas (e.g. a set
of XML Schemas) that describe the structure of a metadata record
conforming to this DCAP." 
This seems to me to be an implicit acknowledgment that DCAP is not
enough to allow machine processing of Application Profiles, which where
the aim, right? So, I wonder if the current approach is too simplified.

These where just some quick thoughts, I might have time to send some
more feedback later.


/Matthias
-- 
Matthias Palmer <[log in to unmask]>

-------------------------------- end cut -------------------------


On Fri, 2004-12-10 at 18:15 +0000, Rachel Heery wrote: 
> Greetings,
> 
> On behalf of the CEN MMI-DC Workshop[1] project team I
> should like to circulate and ask for comment on a Final Draft of
> 
> Guidelines for machine-processable representation of Dublin Core
> Application Profiles this CEN Workshop Agreement.
> http://www.ukoln.ac.uk/metadata/cen/ws-mmi-dc/
> 
> The MMI-DC Workshop provides an open forum in which Dublin Core-related
> issues are addressed at the European level. The Workshop's activities are
> complementary to the work done within the international DCMI context.
> 
> These guidelines propose a detailed data model as the basis for both human
> readable and machine-processable DCAPs. They build on and extend the
> previous CEN Workshop Agreement 14855:  Dublin Core Application Profile
> Guidelines [2], issued in 2003.
> 
> As editor of the guidelines I should like to welcome comments over the
> coming week i.e. by 16 December, apologies for the short notice, due to
> unavoidable deadlines.
> 
> Best wishes,
> 
> Rachel
> 
> 
> [1]
> http://www.cenorm.be/cenorm/businessdomains/businessdomains/isss/activity/wsmmi.asp
> 
> [2]
> http://www.cenorm.be/cenorm/businessdomains/businessdomains/isss/cwa/cwa14855.asp
> 
> 
> ---------------------------------------------------------------------------
> Rachel Heery
> UKOLN, University of Bath                       tel: +44 (0)1225 386724
> http://www.ukoln.ac.uk