> 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
> 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
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
I'm using it as either a personal or corporate name. In my original
I mixed the XLink and MODS standards to demonstrate an example. I think
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
we think about typing that URI into our browser. A URI is just a handle.
can be used to represent any value. For example, I often place the
URI's in XML created from Authority or Bibliographic records:
Now, you know darn well that LC doesn't have any documents at those
nor will I get an authority or bibliographic record when I use those URI's.
URI's in these cases are just a handle to identify that I'm talking about
specific authority or bibliographic record [wish LC would bless this
or another]. Those URI's above can be used in an online or offline context,
are only handles to the record, not the actual record. Now if LC wanted to
records available at those locations, they certainly could.
URI's are just handles, that may or may not actually retrieve documents.
Bray speaks about this all the time where people have the misconception that
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
just handles and not to expect that documents may be at the end point. Note
could have specified the above URI's with different handles, like:
MODS needs to use URI's in many places instead of coded values. As I
above URI's can be used just like coded values. The huge benefit you gain
using URI's instead of coded values is that URI's can be user defined, as
to physically changing the Schema (or creating a new one based on the
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.