LISTSERV mailing list manager LISTSERV 16.0

Help for MODS Archives


MODS Archives

MODS Archives


MODS@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

MODS Home

MODS Home

MODS  March 2002

MODS March 2002

Subject:

Re: Typeless names

From:

Priscilla Caplan <[log in to unmask]>

Reply-To:

Metadata Object Description Schema List <[log in to unmask]>

Date:

Thu, 28 Mar 2002 14:21:23 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (51 lines)

At 11:28 AM 3/27/02 -0500, you wrote:
>> I don't think that you want to remove the distinction between names but
>> you do not need separate tags.  Basically, you can think of the problem
>> you describe in terms of what the XLink standard does with its "role"
>> attribute.  The "role" attribute in the XLink standard allows you to
>> define a relationship to the object you are describing.  The benefits
>> of thinking in an object/relationship fashion is that you only need to
>> define one generic object and some standardized URI's for relationships.
>>
>> 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>
>>
>> The MODS standard would define the "object" [in MODS context is would
>> be called aspect], e.g. <mods:name> where any name can be placed.  The
>> mods:role attribute could be optional, in which case the contents of
>> the object is a name with an undefined relationship.  The MODS standard
>> would then create the following URI's for use in the mods:role attribute:
>>
>>   http://www.loc.gov/mods#conference
>>   http://www.loc.gov/mods#corporate
>>   http://www.loc.gov/mods#personal
>>
>> As an implementer, if I needed to make the distinction between "for
>profit"
>> and "not for profit" corporations then I could define my own URI's to be
>> used as roles.  The important point here is that I still would specify the
>> aspect, e.g. XML element, as <mods:name>.  Anyone making use of the
>metadata
>> would know that <mods:name> is a name aspect of the metadata object.  What
>> role that name is playing in the relationship to the metadata object may
>or
>> may not be important to the person/program using the metadata.

Jumping into this discussion somewhat late...

First, isn't it the "type" attribute of the MODS <name> element that
carries the information "personal", "corporate", "conference"?   The "role"
attribute is for something quite different, the role of the named entity in
relation to the object.

Second, what's the party line on using URI's as attribute values?  I don't
believe this is accomodated in the current schema.

p

Top of Message | Previous Page | Permalink

Advanced Options


Options

Error during command authentication.

Error - unable to initiate communication with LISTSERV (errno=111). The server is probably not started.

Log In

Log In

Get Password

Get Password


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager