On Wed, 1 Mar 2000, Thomas Baker wrote:

> On Wed, 1 Mar 2000, Sigfrid Lundberg, Lub NetLab wrote:
> > Simon Cox wrote:
> > > Structured values/value components are NOT a part of the Dublin CORE - 
> > > only elements are.  You can represent the semantics of components/structure 
> > > by "adding in" a structure to the leaf node.  But the definition of such 
> > > structures is much better done outside the core.
> > 
> > But the container of the structure is, and that's the point. If we, like
> > Tom did, state that qualifiers are either "element qualifiers" or
> > "encoding schemes" then we preclude structure, period. I realize that he
> > didn't mean that, but that is what he de facto said.
> 
> And that actually is what I meant to say.  Components of structured
> values *should* be defined outside the Core, as Simon says.  
> 
> When we cross the boundary from semantics to syntax, and when we
> propose "sub-elements" that stand in a HASA relation to an element
> (Creator HASA Affiliation), and when we start packaging sets of
> sub-elements into schemes for the purpose of interoperability within
> specific communities, we are leaving the realm of defining elements per
> se and entering the realm of prescribing usage.  As Simon also says,
> such schemes could certainly be "recommended for interoperability" by
> DCMI, but they should not be part of the Core.  

Then I just don't understand. I there is no way to say, that what follows
does have a structure, how on earth should a DC-processing piece of
software be able to understand it. I'm not saying that the structure _has_
_to_ _be_ _defined_ within the DCMES.

Rather, I'm saying that the DCMES must acknowledge that there exist
structure, and that structured values belong to a certain class of
qualifiers. That might be quatropilotectomy, but it is a very important
distinction for me.

> Using an analogy from natural language, it is like the difference
> between a dictionary (in the stricter sense) and a usage guide or
> encyclopedia.  Both are urgently needed.
> 
> > One of my problems with the DCMI is that my memory is very much better
> > than most people's I know. Whenever an agreement has been reached, I take
> > for granted that this agreement is valid until we _explicitely_ agreed
> > something else in the issue, whereas most you produce "new" analyses of
> > old problems without ever looking back to what we did three years ago. 
> 
> Sigge, I appreciate your frustration.  However, from a process point of
> view, documents such as [1] and [2], which date largely from 1997 and
> 1998, have remained Working Drafts of working groups and were never
> shepherded through to Proposed or Recommended status.

Yeah, they were no fun anymore...

> They also deal to a large extent with the expression of DC in the RDF
> syntax, which does not currently have the status of a canonical syntax
> for DC.  Perhaps it should some day, but the Web infrastructure is not
> there yet. 
> 
> Moreover, some contributors to those drafts and decisions feel today
> that they are wrong in crucial respects.

Sure, but they were not revised to remedy that. Instead we do as usual,
throw them in the bin and start to work with something which is more fun.

> While I recognize that old issues keep coming up and very much
> appreciate your historical memory, I do not feel that we are actually
> overturning previous decisions from a process point of view. 
> 
> Tom

Sigge

> 
> 1. http://www.ukoln.ac.uk/metadata/resources/dc/datamodel/WD-dc-rdf/ 
> 2. http://www.mailbase.ac.uk/lists/dc-datamodel/files/decisions.html
> 
> _______________________________________________________________________________
> Dr. Thomas Baker                                            [log in to unmask]
> GMD Library
> Schloss Birlinghoven                                           +49-2241-14-2352
> 53754 Sankt Augustin, Germany                              fax +49-2241-14-2619
> 
> 



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%