First of all, I like the terminology you propose... is the following
what I understand you to say?
compact form: unqualified and conventions for simple
qualifications; metadata suitable for embedding in HTML
extended form: potentially rich metadata, the structural
requirements for which are supported in RDF
I've been casting about for a better terminology than qualified versus
unqualified. Anyone see any problem with this?
OK... that's the easy part.
Siggy... You propose, I believe, a basis for a compromise between the
two position. Can you write up a synopsis highlighting them and put it
out for discussion? ( I'm sorry to ask you to re-say what's been said,
but articulating the two positions side by side in a concise fashion may
help.).
As for what the RFC says, if there is a problem that can be resolved by
working out these positions, we can fix it. I am reluctant to continue
niggling about these things, but better to eat crow while its young and
tender.
Let me point out that interest in standardization of the Dublin Core is
growing (and growing more important), and that provides us with an
additional milestone towards which we might work.
> -----Original Message-----
> From: Sigfrid Lundberg [SMTP:[log in to unmask]]
> Sent: Monday, March 23, 1998 8:59 AM
> To: [log in to unmask]; [log in to unmask]
> Subject: Re: Relations Working Group Report
>
>
> I strongly disagree with the way the relations element has been
> handled the last few months.
>
> Firstly, the issue of the DC.Relation.Type and DC.Relation.Identifier
> dichotomy has been raised by Andy Powell
> (<URL:http://www.roads.lut.ac.uk/lists/meta2/1998/02/0030.html>) and
> myself
> (<URL:http://www.roads.lut.ac.uk/lists/meta2/1998/02/0038.html>)
> We never got any responses on our views.
>
> Secondly, there is differences between the qualified DC RFC as posted
> on this
> (<URL:http://www.roads.lut.ac.uk/lists/meta2/1998/02/0002.html>) list
> and the document
> <URL:http://purl.oclc.org/metadata/dublin_core/wsubelementdraft.html>
> Why is there? Isn't the RFC going to be the authoritive document? Or
> is the RFC going to be revised?
>
> Thirdly, the DC.Relation.Type and DC.Relation.Identifier dichotomy
> makes implicit assumption of a syntax which is of another kind than
> for all other proposed subelements. It is my conviction that the we
> need a small set of core sub-elements, and they should all be possible
> to use also in the simplest encodings, and its usage should be
> coherent.
>
> The Date, Coverage and The-Other-Subelements working groups all
> propose a
> substructure which is coherent and adhere to the Canberra qualifier
> philosophy. Neither of which requires a grouping mechanism (as is
> available in RDF). All three proposals are compatible with the older
> HTML
> v2-3.2 and HTM 4.0 syntaxes. The embedding of relation metadata of the
> kind that is required in
> (http://www.roads.lut.ac.uk/lists/meta2/1998/03/0003.html will be
> significantly harder to parse for harvesting robots, and will break
> existing Dublin Core implementations.
>
> The HTML meta-tagging is a dirty hack, a kludge. But we don't have to
> make
> it even worse, do we? Therefor I urge that we return to the semantics
>
> in the original proposal
> (<URL:http://www.roads.lut.ac.uk/lists/meta2/1997/12/0046.html>).
>
> However, In connection with the earlier discussion on Relation, I
> proposed
> that we should start talking of DC metadata in _compact_ and
> _extended_
> forms (see
> <URL:http://www.roads.lut.ac.uk/lists/meta2/1998/02/0038.html>). In
> that
> vocabulary I would say that the relations working group's proposal now
> is
> in an extended form, whereas their original posting was using the
> compact
> form.
>
> I think that it is important that we are aware of existence of these
> two
> forms and we do need both, but we should never mix the two.
>
>
> Good afternoon
>
> Sigfrid
|