 |
 |
> 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.