> From: Karen Coyle [mailto:[log in to unmask]]
> Sent: Friday, March 29, 2002 03:13 PM
>
> At 10:31 AM 3/27/2002 -0500, Houghton,Andrew wrote:
> >Implementers can define additional relationships, by using their own
> >URI's. What's important here about "role" is that the
> "object" is still
> >the object. You are not redefining the "object" but how you
> are using
> >that object. As far as the MODS standard it could implement this as
> >the following:
> >
> > <mods:name
> mods:role="http://www.loc.gov/mods#conference">...</mods:name>
>
> A couple of comments here that echo those of Pricilla...
>
> 1) "conference" is not a role, it's a type of entity that can
> be considered
> responsible for the intellectual content of a document. Role
> is something
> like "editor" or "translator" or "illustrator" -- the role
> that person or
> entity played in the creation process (since there are lots
> of kinds of
> creation acitvities, especially when you get into areas like film).
Hmm... Actually you and Pricilla quoted me out of context from the
reply to Geoff's complaint about MARC21. In addition, my reply about
good markup made use of the role attribute in MODS and XLink where
it's used in different contexts. Geoff's complaint was that MARC21
has several tags for names, e.g. 100, 110 and this makes it difficult
for other non-library communities to use MARC21 as a standard.
My point was that _if_ you were to translate MARC21 into an XML encoding,
like MODS does, it would not be considered good markup practice if you
were to have two or more elements like:
<PersonalName ... />
<CorporateName ... />
You can think of this in OO (Object Oriented) terms. What you really have
here is PersonalName and CorporateName are really sub-classes of the class
Name. So it would be considered good practice to have one element named
Name and then specify the context is how that was being used. I then
pointed
out that XLink, which deals with resources and relationships, uses it role
(also, arcrole) attribute to indicate how the resource or relationship is
being used. So in the context of PersonalName and CorporateName you could
produce markup like:
<Name role="urn:name-schema:personal" ... />
<Name role="urn:name-schema:corporate" ... />
What this says is that you have a class of Name but in this particular
context
I'm using it as either a personal or corporate name. In my original
discussion
I mixed the XLink and MODS standards to demonstrate an example. I think
this
is what confused both of you. I went from theory to example too quickly.
> 2) Any place where you have URI's you have to also plan for
> off-line uses
> of the records. I'm always very reluctant to have URI's added to data
> standards in any area where the interpretation of the data or
> the immediate
> use of the data is dependent on the URI and a functioning connection.
You have some misconceptions about URI's. A URI does not need to point to
anything to be functional. By convention when we see
http://www.loc.gov/mods/
we think about typing that URI into our browser. A URI is just a handle.
It
can be used to represent any value. For example, I often place the
following
URI's in XML created from Authority or Bibliographic records:
http://www.loc.gov/marc/authority#sh85-021262
http://www.loc.gov/marc/bibliographic#99-382295
Now, you know darn well that LC doesn't have any documents at those
locations,
nor will I get an authority or bibliographic record when I use those URI's.
The
URI's in these cases are just a handle to identify that I'm talking about
some
specific authority or bibliographic record [wish LC would bless this
convention,
or another]. Those URI's above can be used in an online or offline context,
they
are only handles to the record, not the actual record. Now if LC wanted to
make
records available at those locations, they certainly could.
URI's are just handles, that may or may not actually retrieve documents.
Tim
Bray speaks about this all the time where people have the misconception that
if
a URI starts with http: or ftp: that people expect a document to be at that
location. The URI RFC's and documents on the W3's site point out that URI's
are
just handles and not to expect that documents may be at the end point. Note
I
could have specified the above URI's with different handles, like:
about://www.loc.gov/marc/authority#sh85-021262
about://www.loc.gov/marc/bibliographic#99-382295
javascript://www.loc.gov/marc/authority#sh85-021262
javascript://www.loc.gov/marc/bibliographic#99-382295
urn:loc-gov:marc:authority:sh85-021262
urn:loc-gov:marc:bibliographic:99-382295
MODS needs to use URI's in many places instead of coded values. As I
indicated
above URI's can be used just like coded values. The huge benefit you gain
by
using URI's instead of coded values is that URI's can be user defined, as
opposed
to physically changing the Schema (or creating a new one based on the
existing
one) to implement new coded values.
While you can make MODS track MARC21 exactly, it doesn't help those other
non-library communities that use different standards. If you want to reach
those other communities then don't use coded values that only make sense
to MARC21 catalogers. Using URI's is a way around this problem. MODS can
and should define a set of URI's that allow roundtriping of MARC21 to MODS
to MARC21. Other non-library communities can standardize URI's that make
sense to their community. The MODS specification stays the same and nobody
needs to redefine the Schema to suit their personal needs.
Andy.
|