From: Misha Wolf
Responding to: Bernhard Eversberg (appended)
I wrote extensively about sub-elements a few months ago but have been too
busy on other matters to read recent DC mail. Last time I did so, there was
a lot of confusion about the terms:
- "sub-element", and
- "type".
Most people appeared to think of them as one and the same, leading to
erroneous constructs such as:
DC.Creator.PersonalName
and:
DC.Creator.PersonalName.Address
I'll offer here a formal definition of sub-element: It is exactly analogous
to "child" in the following definition taken from section 2.1 of the XML
Specification [1]:
> ... for each non-root element C in the document, there is one other
> element P in the document such that C is in the content of P, but is not
> in the content of any other element that is in the content of P. P is
> referred to as the parent of C, and C as a child of P.
^^^^^^ ^^^^^
[Emphasis in the original]
Now a "type" is something quite different. Some examples are:
- "this Number if of type Integer",
- "this Creator is of type Person",
- "this Relation is of type IsPartOf".
In each case, the left-hand object (Number, Creator, Relation) takes one of
a number of possible values (such as Integer, Person, IsPartOf). The
possible values of each object can usually be enumerated.
Some extracts from my mail of October 22 follow:
> It is my view that ... the "correct" metadata would look rather like this:
>
> DC.Creator.Name="Misha Wolf"
> DC.Creator.Address="85 Fleet Street"
> DC.Creator.Type="Person"
>
> and:
>
> DC.Date.Value="1997"
> DC.Date.Type="Created"
>
> and:
>
> DC.Relation.Type="Some-relation-type"
> DC.Relation.Identifier="http://www.somewhere.org/abc"
>
> In this example, it is clear that "Type" refers to a type of Relation.
> Similarly, in the previous examples, "Type" referred to a type of Creator
> and to a type of Date, respectively.
>
> All of this is much clearer when written out using XML (no, this isn't RDF):
>
> <DC:Creator>
> <Name>Misha Wolf</Name>
> <Address>85 Fleet Street</Address>
> <Type>Person</Type>
> </DC:Creator>
>
> <DC:Date>
> <Value>1997</Value>
> <Type>Created</Type>
> </DC:Date>
>
> <DC:Relation>
> <Type>Some-relation-type</Type>
> <Identifier>http://www.somewhere.org/abc</Identifier>
> </DC:Relation>
Turning to what Bernhard refers to as a "subfield", I would argue that
semantically this is the same as a sub-element, but that the older
technology used subfield markers within strings, while newer technology uses
XML tags. I believe it is very easy to convert DC records written in XML to
and from database fields.
As it happens, some members of the DC community are still advocating
approaches similar to the "subfield" approach, ie placing logically distinct
pieces of information into a single element and using various delimiters to
distinguish them.
With XML (and RDF) round the corner, I hope we aren't going to shoot
ourselves in the foot by designing for outdated technology.
[1] http://www.w3.org/TR/PR-xml
----------------------------------------------------------------------------
Misha Wolf Email: [log in to unmask] 85 Fleet Street
Standards Manager Voice: +44 171 542 6722 London EC4P 4AJ
Reuters Limited Fax : +44 171 542 8314 UK
----------------------------------------------------------------------------
12th International Unicode Conference, 8-10 Apr 1998, Tokyo, www.unicode.org
7th World Wide Web Conference, 14-18 Apr 1998, Brisbane, www7.conf.au
> Is "Subelement" a term, I wonder, that has been fixed in the DC vocabulary?
>
> I'm asking because in the librarian's vocabulary, "subfield" means something
> entirely different, it is a part of a field's content, labeled by subfield
> marker within the string that constitutes the field. A DC subfield is not
> like this, it is rather a separate field. And since there's no link of any
> kind tying DC elements to each other, and no specified order of arrangement,
> "subfield" and "subelement" have nothing in common indeed.
>
> Apart from this purely terminological question, I find it highly desirable
> to have a way of tying elements together that belong together, because
> with repeatable elements you get into a hell of a mess when you want to
> sort everything out by software and convert DC records into database records.
> Is this to be expected no earlier than when we eventually get RDF? Why was
> it impossible to have structure (syntax) within a DC element's content? For
> then, the whole problem could have been avoided and subfield / subelement
> could be the same concept.
> Sorry, but I'm obviously not in the picture about the reasoning behind some
> DC basics...
>
> B.E.
>
>
>
>
> Bernhard Eversberg
> Universitaetsbibliothek, Postf. 3329,
> D-38023 Braunschweig, Germany
> Tel. +49 531 391-5026 , -5011 , FAX -5836
> e-mail [log in to unmask]
------------------------------------------------------------------------
Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of
Reuters Ltd.
|