Hi Ann,

> What concerns me about these new XML coding ideas is how - 
> and whether - they'll be used in practice. I think there is a 
> real danger of putting people off following a recommended 
> DC-in-XML serialisation. So they'll just continue to use the 
> old 'fuzzy' form with their own additions.
> 
> I'm currently thinking about an XML serialisation of an 
> application profile for a community that I suspect knows 
> little about XML or about DC (at the abstract model level).

This is the nub of the problem, it seems to me: (IMHO) the developers of
systems working with DC metadata _do_ need to understand the DCMI
Abstract Model. 

That is not to say that the (human) users of those systems have to
understand it - data creators will use whatever sort of data entry forms
are designed for data creation by the developers and "end users" will
see whatever sort of displays the developer provides for buying books or
CDs or booking hotels or whatever. None of them need to know anything
about the DCAM or see XML documents. (In just the same way that neither
an Amazon cataloguer nor an Amazon shopper needs to understand the
entity-relational model or the RDBMS schema used in their database.) 

Nor does it mean that the internal data structure of a system using DC
metadata has to be based on the DCAM. The data can be stored in an RDBMS
or plain text or some XML format and mapped to the DCAM description
model, and to a digital format for representing that description model.


> I 
> was debating with myself whether I could include, and explain 
> the reason for:
> 
> <dc:title>
>   <dcx:ValueString>My Document</dcx:ValueString> </dc:title>
> 
> rather than:
> 
> <dc:title>My Document</dc:title>

The justification for the XML format would have to be based on the DCAM
and the concept of the DC description set. If the other party thinks in
terms of, say, attribute-value pairs, and we don't explain that that DC
metadata isn't based on attribute-value pairs, then, yes, I agree that
it is hard to make an argument for the more complex format.

> I suspect not. So I think 
> 
> <dcx:statement 
> dcx:propertyURI="http://purl.org/dc/elements/1.1/title">My 
> Document</dcx:statement>
> 
> is probably a non-starter, though at least it doesn't go to a 
> second level.

Erm, I think Andy was alluding to the proposal in the wiki and that
_does_ use a dcx:valueString child element. ;-)

i.e.

 <dcx:statement 
 dcx:propertyURI="http://purl.org/dc/elements/1.1/title">
    <dcx:valueString>My Document</dcx:valueString>
 </dcx:statement>

> I would have thought that people who wanted 
> that sort of precision in modelling would use RDF anyway.

I'm not sure what you mean by "precision in modelling". If we are basing
our work on the DCAM, then that means we are adopting the notion of the
DC "description set" as the basis of DC metadata. 

The DCAM defines the DC "description set" as an "information structure",
if you like, and it tells me the component parts which make up that
structure. According to the DCAM, a statement contains:

- exactly one property URI and
- zero or one reference to a value in the form of a value URI
- zero or one vocabulary encoding scheme URI 
- zero or more representations of a value

where a value representation is either

- a value string
- a rich representation

(and so on.)

If we are to represent that information structure in XML then we need an
XML format that enables us to distinguish in the XML structure those
different components that are distinguished in that information
structure. i.e. to allow an "encoding" application to serialise an
instance of that information structure into an XML instance, and a
second "decoding" application to read that XML instance and create a
"description set" from it.

Now there are a huge number of ways of doing that in XML (using XML
element content, the values of XML attributes, the names of XML
elements, the names of XML attributes, XML attributes acting as flags,
relationships between XML elements, relationships between XML elements
and XML attributes, ID/IDREF relations etc etc etc etc. We could even
invent hacks for putting things inside comments! (Didn't weblog
trackback work like this at some point?)) It doesn't mean we have to
have XML elements called "description" and "statement", but we do need
to specify how the things in the XML instance correspond to the things
in a DC description set.
  
> A problem with the first construct above - as well as having 
> to explain what the 'ValueString' part is for - 

Again that comes back to explaining that the XML format is based on the
DCAM and the concept of the description set.

> is that it 
> goes down a level in the XML document, making life harder for 
> a consuming application.

I don't quite understand how the first form make anything harder for an
application? Why is a search for the content of
dcx:description/dc:creator/dcx:valueString harder than a search for the
content of dcx:description/dc:creator?

What the first form enables me to express (and the second doesn't) is
that there are two value strings (optionally with different language
tags or syntax encoding schemes) associated with the same value, which
is what the DCAM description model says the structure of the description
set should allow for.

(But see below re subsetting/profiling.)

> Is there an option of including an abbreviated form, with the 
> 'valuestring' level implicit, for simple cases? Ie. 
> <dc:title>My Document</dc:title> is shorthand for and implies 
> <dc:title><dcx:ValueString>My Document</dcx:ValueString></dc:title>

It becomes complex for a conusming application to have to deal with two
different forms, both labelled as a single XML format. 

Suppose I'm developing a service that harvests "dc-xml" data from
multiple sources, and I have to allow for the possibility that some of
my sources use the "short" form and some sources use the "full" form. 

Either

(a) I have to use some sort of "normalisation" pre-processing that maps
my data to one form; or
(b) for every operation on my aggregated data, my application has to
handle both forms 

(FWIW, it also becomes complex working with this sort of content model
in W3C XML Schema, but I'm not using that as a "show-stopper" argument.)


Now then, what _would_ be possible is to define distinct XML formats
that support _different_ subsets (profiles, if you like, though I
hesitate to use that term as it is already used for other purposes in
the DCMI context) of the DCAM description model. 

We could define a subset of the DCAM description model in which, say,
only one value string per statement was supported and rich
representations were not supported, and then specify an XML format that
supports only that subset (let's call it dc-xml-minimal) and have a
second format (let's call it dc-xml-full) that, like the current
proposals, that supports the full model.

In this case, if a service provider is getting dc-xml-minimal from some
sources and dc-xml-full from others, at least the two formats are
explicitly labelled and the application "knows what to expect".

We could even decide that the XML format provided by DCMI should only
support a subset of the DCAM description model i.e. dc-xml becomes
dc-xml-minimal and we forget about "dc-xml-full". (But I suspect that
rather begs the question of why we bothered defining that level of
complexity in the DCAM in the first place if we aren't going to offer
any way of representing it in a concrete syntax.)

We did consider this possibility of profiling/subsetting when we drafted
the current proposal, because a format which supports all the features
of the DCAM description model is, almost unavoidably, quite
verbose/complex at least when compared with the current recommendation,
because the models used in the current recommendation are much simpler
than the DCAM. (Though having said that, I think the current proposal
could be made more concise by e.g. abbreviating some of the XML element
and attribute names and maybe re-thinking the use of
namespace-qualification for attributes). We decided to go with a single
proposal based on the full model in the first instance.

And I have some earlier work that is based on such a subset/profile of
the DCAM description model (which I think was based on "one value string
per statement, no rich representations", but I'd have to dig back and
check).

But if we do take such an approach, it remains the case that we need to
work on the basis of providing an XML format for that subset/profile of
the DCAM description model, and that should be the basis for explaining
the format to others. 

So really I guess we need to decide whether we want an XML format that
supports the full DCAM description model, or whether we want an XML
format that supports some subset of it (and if so what subset), or
whether we want both.

> I guess the serialisation I'm working on will have to be 
> based on the old schemas anyway, because the new schemas are 
> not yet decided.

Pete