Date:         Thu, 21 Oct 2004 07:38:47 -0700
Reply-To:     Metadata Object Description Schema List <[log in to unmask]>
Sender:       Metadata Object Description Schema List <[log in to unmask]>
From:         Karen Coyle <[log in to unmask]>
Subject:      Re: info:xv proposal
Comments: To: Metadata Object Description Schema List <[log in to unmask]>
In-Reply-To:  <[log in to unmask]>
Content-Type: text/plain

On Thu, 2004-10-21 at 06:37, Andrew E Switala wrote:
>  And as we know, keeping two versions of the same
> list
> > is fraught with perils.
>
>     Maintain only the machine-readable list, from which the
> human-readable list can be algorithmically generated.

Actually, there is no machine-readable list in the info URI registry, as
I understand the registry. Take a look at:
  http://info-uri.info/registry/index.html

The registry appears to register only the upper level, that is the
namespace. So somewhere else (and the info URI itself is not
dereferenceable) you have a list that one has to validate against. And
since to a computer any list of values is just a dumb string, there
isn't any difference between validating against:

   info:xv/1/mods/titleType/alternative

rather than

   alternative

So I'm not swayed by the "easier to validate" arguments. What Ray's
design DOES do, is it gives us potentially a single list, since the list
format contains the list name plus the values. If we assume that having
a single list is a good idea (and that systems can grab it dynamically,
so we now can update the list and therefore update the standard "on the
fly" so to speak), then we still could consider a list with the format:
   titletype#alternative

or any of a number of different similar formats.

And then you do have what you used as an example for RDF:

>     It makes the RDF folks happy.  And URIs beyond the info variety can
> make "type" and "authority" attributes more than just wishful thinking,
> e.g.
>     <subject authority="http://example.org/authfile.xml">
>         <topic>widgets</topic>
>     </subject>

which is not what this proposal does. This proposal does not have an
authority list, it has a separate URI value for each entry in what was
once an authority list.

> In some cases they might even do away with type attributes altogether,
> e.g.
>     <identifier>urn:ISSN:0000-0000</identifier>
> rather than
>     <identifier type="issn">0000-0000</identifier>
> They help make documents more self-describing, e.g. the Dublin core
> URIs that point to RDF descriptions of their usage.

I have to be honest -- I'm not a great fan of RDF. I see it as all form
and little substance. In other words, RDF is syntax, and what I really
care about is semantics. (I call the "semantic web" the "syntactic web."
There are no semantics without humans.) The string "urn:ISSN:0000-0000"
does not lead a program to "understand" any more than "type="issn"." If
it really is a convenience for validating, then let's come up with a
convenient way to validate our authority lists. But first, let's think
about what we need to do before we start working on solutions. So here's
one version (mine, too early in the morning, only one cup of tea) of our
problem set:

1) We have a large number of independent lists that have to be
maintained.
2) Some of these lists were developed for MODS, some are MARC lists, and
there are folks who probably want to create their own lists.
3) We want to make it easy to propagate these lists to users and to
programs.
4) We want to make it easy for humans to understand the lists and their
values, since they have to select the proper values from them when
creating records.
5) We want to make it easy for programs to validate the values in
MODS/MADS records.
6) ?? add more here

Because we are getting down to the value level, and because we do want
there to be semantics (URIs do not have semantics), we might want to
consider a (machine-readable) data dictionary rather than URIs as the
underlying structure for our values. (And, no, I'm not channeling Norman
Paskin, thank you.)

--
-------------------------------------
Karen Coyle
Digital Library Specialist
http://www.kcoyle.net
Ph: 510-540-7596 Fax: 510-848-3913
--------------------------------------