Philip, I've been meaning to put in a "me too" for what you posted. I
have many of the same questions about the metadata terms. Some more
specifics, below:
Philip Davis wrote:
*Questions*
**
I was greatly puzzled by the indecs Attribute Types. I could not
understand why that particular set of terms had been chosen.
Ditto. As I have surmised before (I can't remember if it was on this
list or not), at the time that RDA was first being developed, the indecs
model may have been the most sophisticated and most circulated one
around. However, it hasn't proven to have endured, and even indecs
doesn't seem to exist any longer. In 2002 the DOI organization announced
that it had based the DOI on indecs, and there was overlap between the
people developing indecs and EDItEUR, which has some obvious interaction
with DOI. That would have been around the time that the first work was
being done on RDA, so this could have historical roots.
Basicaly, I think it is time to look at the indecs model (which is hard
to find since the web site no longer exists -- you can still find it at
the Internet Archive's archived version of the http://www.indecs.org web
site) and decide whether or not to keep its structures in our metadata.
In addition, I personally don't agree with the interpretation of the
indecs Attribute Types that appears in RDA. I don't have time right now
to go into that, but keeping that in there, IMO, is not a good idea.
Long
reflection, however, has led me to ask the following question. Is there
a correspondence between the Attribute Types and the present order of
chapters in RDA?
This is somewhat different, but I looked at the FRBR attributes
side-by-side with the RDA document headings and could find no
correspondence at all. I'm assuming that the FRBR attributes were well
thought-out, but I can't find an organizing principle in them, and am
even more puzzled when they don't appear in an obvious way in RDA.
If the ultimate aim is to use Resource Description Framework, why are
DCAM and indecs being used now?
I think that DCAM and indecs are frameworks at a different level to RDF.
You can express DCAM in RDF (I think, anyway). RDF is pure structure
(the triples, as you mentioned); indecs is more like FRBR -- it has
content and defines an area that will be served with a metadata
development. (Note: indecs was developed in the area of e-commerce, not
descriptive metadata.)
I have found the wording on the web sites relating to metadata terms to
be often abstruse. For example 'literal value surrogate: a value
surrogate for a literal value, made up of exactly one value string (a
literal that encodes the value)'-(DCAM Section 7). I realize that part
of the problem is my lack of familiarity with the terms and that some of
the concepts may be difficult to define and discuss. Is there an
introductory guide in plain English that I might consult?
Oh, dear. I fear that the authors of that probably thought they WERE
writing in plain English. (Like the programmers who answer your
questions with: just read the code; it's as easy to read as English.) My
interpretation of the contorted sentence you cite is that the "value
surrogate" is like the codes in the MARC fixed fields, where "b" can
mean "no dates given" and "eng" means "English language."
MARC uses the international language of numbers for its codes. A system
using XML is language specific. If international exchange of data is to
be achieved, the XML records will need to be presented in different
languages. To what extent will the use of Unicode or other methods solve
this problem?
First, XML doesn't have to use language-based tags. You can create an
XML schema that encodes a title with "<245> </245>". Basically, if you
can type it, it can go between the pointy brackets. For example, here's
a chunk of an ONIX record that is encoded in XML and has the ISBN in it:
<productidentifier>
<b221>15</b221>
<b244>9781841768472</b244>
</productidentifier>
It uses both English-like codes and real code-like codes ("b221"). It's
all in how you design your XML schema.
Unicode is a way to encode different character representations (eg all
those characters including and beyond the ones on the English keyboard
I'm using right now), but I don't think it does anything that directly
aids in translation from one language to another.
I don't think the translation part is difficult -- not technically,
anyway. Many software packages do this already today since they want to
sell that same software in many different countries. They have an
internal code or representation (like "245") and the conceptually
there's a table that goes something like:
code eng fre ita
245 title titre titolo
Well, that probably doesn't display correctly, but that's the idea. And
the translation can be whatever designers want -- in any character set,
using words or phrases, images, whatever. When you install the software
they ask you what language you want the interface in, and it applies the
correct column from its table to your display. Because of this, I don't
think we have to worry about what "codes" are used internally for our
metadata, just that what catalogers and end-users see (and those two
will probably be different) will be in their language. If we should
decide that the language of catalogers is MARC codes, that could be the
choice for their display.
kc
--
-----------------------------------
Karen Coyle / Digital Library Consultant
[EMAIL PROTECTED] http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
