Superfluous Wrappers or Top Level Elements

[melanieWacker]

Wrappers (or top level elements used to group similar elements together) have been eliminated for and The individual elements are now represented as direct properties. For more background see: Development of a MODS RDF Ontology: Discussion Points Ray Denenberg, Library of Congress, November 4, 2013 1) Are there use cases that would lead us to carry those wrappers over? 2) Are there other wrappers that can be eliminated?

[melanieWacker]

The two wrapper elements that have so far been eliminated are originInfo and physicalDescription. 1) physicalDescription: I can only think of the example of oral history catalog records where we would repeat the physicalDescription element for the transcript and for the audio medium. So without the wrapper it would be impossible for a program to tell if the extent relates to the transcript or the tape. However, we would not describe oral history interviews in MODS, and I cannot come up with an example in our MODS environment that would require us to retain this wrapper. Other use cases? 2) originInfo: What is the relationship to the 264 in MARC? Do we need to make sure that we have attributes that allow for the expression of the different roles, e.g. place of maufacture vs. place of publication if we eliminate the wrapper?

[raydAtLC]

"Do we need to make sure that we have attributes that allow for the expression of the different roles, e.g. place of manufacture vs. place of publication if we eliminate the wrapper?"

I think we need to express these roles, wrapper or not. It seems fairly well-accepted that the MODS XML originInfo is broken, that is to say, it doesn't express these roles as is. There is a single element with no attribute to express role. This, in contrast to date, which has several elements expressing different roles. These date XML elements translate directly to rdf properties (in the LC RDF) but place is just place. So, the solution would seem to be to define separate properties placeOfManufacture, placeOfPublication, etc. But that isn't going to help if what you are doing is converting an existing MODS record to RDF. It would help for (a) original cataloguing (b) converting MODS records with a later version that fixes this problem. And I think there have been several attempts to come up with proposed approaches to fix it, both for 3.x and 4.0. One of us should dig these up.

But I want to reiterate I don't think this is a wrapper issue I think it goes more to the core of originInfo itself. Unless I am misunderstanding the problem.

Ray

From: melanieWacker [mailto:notifications@github.com] Sent: Thursday, March 20, 2014 3:38 PM To: blunalucero/MODS-RDF Subject: Re: [MODS-RDF] Superfluous Wrappers or Top Level Elements (#10)

The two wrapper elements that have so far been eliminated are originInfo and physicalDescription. 1) physicalDescription: I can only think of the example of oral history catalog records where we would repeat the physicalDescription element for the transcript and for the audio medium. So without the wrapper it would be impossible for a program to tell if the extent relates to the transcript or the tape. However, we would not describe oral history interviews in MODS, and I cannot come up with an example in our MODS environment that would require us to retain this wrapper. Other use cases? 2) originInfo: What is the relationship to the 264 in MARC? Do we need to make sure that we have attributes that allow for the expression of the different roles, e.g. place of maufacture vs. place of publication if we eliminate the wrapper?

— Reply to this email directly or view it on GitHub https://github.com/blunalucero/MODS-RDF/issues/10#issuecomment-38211620 . https://github.com/notifications/beacon/4854536__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxMDk2MzQ3NiwiZGF0YSI6eyJpZCI6MjMxNjEwMzR9fQ==--41bedddaccab3f9a5b38107c8bb899a0ee43fb5c.gif

[rguenther52]

As for the relationship with 264, the MODS elements under originInfo (place, publisher and various dates) are intended to map with both the old way of doing it in MARC (260) and the new way under RDA (264). We defined the attribute eventType to show the role in the last version of MODS XML. The main reason to have the wrapper element originInfo is to keep the place with the appropriate publisher and appropriate date. The other elements under originInfo are superfluous. We still need to associate these elements together and perhaps can do it through the property name itself if it includes the role. I will dig up the last message I wrote to the MODS list about this topic (which was in terms of how we might change it in 4.0)

[raydAtLC]

I think this was the “last word” on eventType.

http://listserv.loc.gov/cgi-bin/wa?A2=ind1301 http://listserv.loc.gov/cgi-bin/wa?A2=ind1301&L=MODS-EC&P=R12878&I=-3&X=7AB06F72B927750999&Y=rden%40loc.gov &L=MODS-EC&P=R12878&I=-3&X=7AB06F72B927750999&Y=rden%40loc.gov

This suggests that we might have properties publicationEvent, productionEvent, etc. all with a range of class Event, which has three properties – agent, eventDate and eventPlace.

For the other originInfo elements these would map to sepatate RDF properties, not wrapped – dateCreated, dateCaptured, edition, etc.

Ray

From: rguenther52 [mailto:notifications@github.com] Sent: Monday, May 19, 2014 11:55 AM To: blunalucero/MODS-RDF Cc: Denenberg, Ray Subject: Re: [MODS-RDF] Superfluous Wrappers or Top Level Elements (#10)

As for the relationship with 264, the MODS elements under originInfo (place, publisher and various dates) are intended to map with both the old way of doing it in MARC (260) and the new way under RDA (264). We defined the attribute eventType to show the role in the last version of MODS XML. The main reason to have the wrapper element originInfo is to keep the place with the appropriate publisher and appropriate date. The other elements under originInfo are superfluous. We still need to associate these elements together and perhaps can do it through the property name itself if it includes the role. I will dig up the last message I wrote to the MODS list about this topic (which was in terms of how we might change it in 4.0)

— Reply to this email directly or view it on GitHub https://github.com/blunalucero/MODS-RDF/issues/10#issuecomment-43522119 . https://github.com/notifications/beacon/4854536__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxNjEzNDEyMCwiZGF0YSI6eyJpZCI6MjMxNjEwMzR9fQ==--1d23a1a981fb8f9623da7e1631e1cbcb1013e557.gif

[melanieWacker]

Hi Ray, is there a better link to the posting? This one doesn't seem to work. Thanks!

[rguenther52]

Yes, the link doesn't work. Ray: you also need to take out the &Y=rden%20loc.gov when you send the URL.

[raydAtLC]

Try this:

http://listserv.loc.gov/cgi-bin/wa?A2=ind1301 http://listserv.loc.gov/cgi-bin/wa?A2=ind1301&L=MODS-EC&P=R12878&I=-3&X=7AB06F72B927750999&Y=rden%40loc.gov &L=MODS-EC&P=R12878&I=-3&X=7AB06F72B927750999

From: melanieWacker [mailto:notifications@github.com] Sent: Monday, May 19, 2014 2:29 PM To: blunalucero/MODS-RDF Cc: Denenberg, Ray Subject: Re: [MODS-RDF] Superfluous Wrappers or Top Level Elements (#10)

Hi Ray, is there a better link to the posting? This one doesn't seem to work. Thanks!

— Reply to this email directly or view it on GitHub https://github.com/blunalucero/MODS-RDF/issues/10#issuecomment-43539317 . https://github.com/notifications/beacon/4854536__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxNjE0MzM1NiwiZGF0YSI6eyJpZCI6MjMxNjEwMzR9fQ==--41484b5af2dd5325c8eac1153951774b1fbc23af.gif

[rguenther52]

Still bad but try this: http://listserv.loc.gov/cgi-bin/wa?A2=ind1301&L=MODS-EC&P=R12878&I=-3&X=7AB06F72B927750999

(although I thought there was something more recent than this-- will have to look around).

[raydAtLC]

If you can’t follow the link, here’s the message.

Define attribute @eventType for originInfo.

Suggested values: "production", "publication", "distribution", "manufacture". (Not a controlled list, but recommended.)

Rules.

means that within that :

•   <publisher> is the producer

•   <dateIssued> is the date of production

•   <place> is the place of production

means that within that

•   <publisher> is the publisher

•   <dateIssued> is the date of publication

•   <place> is the place of publication

means that within that

•   <publisher> is the distributor

•   <dateIssued> is the date of distribution

•   <place> is the place of distribution

means that within that

•   <publisher> is the manufacturer

•   <dateIssued> is the date of manufacture

•   <place> is the place of manufacture

  1. For eventType with a value other than one of the above:

These rules do not address this case.

The remaining rules assume that whenever eventType is specified its value is one of the above four.

1. If there is no element with @eventType

there may be any number of elements (without @eventType) and their interpretation is unchanged from version 3.4.

1. When there are one or more elements with @eventType

   • There must  be no more than one <originInfo> element that does not include @eventType.

   • There must be no more than one occurrence of any of <publisher>, <dateIssued> or <place> in any given <originInfo> with @eventType.

   • There must be no occurrences of <publisher>, <dateIssued> or <place> in <originInfo> that omits @eventType.

2. When there are one or more elements, and every one includes @eventType

Any element from the following list may occur, in any number, in any , but each pertains specifically to the in which it occurs.

•   <dateCreated>

•   <dateCaptured>

•   <dateValid>

•   <dateModified>

•   <copyrightDate>

•   <dateOther>

•   <edition>

•   <issuance>

•   <frequency>

  1. When there are one or more elements that includes @eventType, and one element that does not

For any given element among the list in rule 8: it may occur in one or more element that includes @eventType, or it may occur in the element that does not, but not both. So, for example:

•   <frequency> may occur in any number of <originInfo> element that includes @eventType, in which case:

•   each occurrence pertains only to the <originInfo> in which it occurs

•   it must not occur in the  <originInfo> element that does not include @eventType.

•   <frequency> may occur in the  <originInfo> element that does not include @eventType, in which case it must not occur in any <originInfo> element that includes @eventType.

From: rguenther52 [mailto:notifications@github.com] Sent: Monday, May 19, 2014 2:52 PM To: blunalucero/MODS-RDF Cc: Denenberg, Ray Subject: Re: [MODS-RDF] Superfluous Wrappers or Top Level Elements (#10)

Still bad but try this: http://listserv.loc.gov/cgi-bin/wa?A2=ind1301 http://listserv.loc.gov/cgi-bin/wa?A2=ind1301&L=MODS-EC&P=R12878&I=-3&X=7AB06F72B927750999 &L=MODS-EC&P=R12878&I=-3&X=7AB06F72B927750999

(although I thought there was something more recent than this-- will have to look around).

— Reply to this email directly or view it on GitHub https://github.com/blunalucero/MODS-RDF/issues/10#issuecomment-43541857 . https://github.com/notifications/beacon/4854536__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxNjE0NDc0OCwiZGF0YSI6eyJpZCI6MjMxNjEwMzR9fQ==--b5c73022eea9080cdb4d8305916de16f3ae3ec50.gif

[melanieWacker]

Recommendations from 05.20.2014 conference call: OriginInfo: Agreement to create “superclass” event with subclasses for typical events such as publication, manufacture, etc. When event type is not indicated in source data there needs to be a default event, possibly publication. edition, issuance, and frequency should be removed from other originInfo elements and carried forward as separate properties.

[melanieWacker]

Question: What should we name that new event superclass that is going to take the place of originInfo? If we just call it modsrdf:Event that seems a bit broad.

[raydAtLC]

We should not call it event. In BIBFRAME it's event but that's going to change at some point (hopefully soon) when we introduce the concept of an event, as in a performance, etc.

We need another term, one that generalizes production, publication, distribution and manufacture. Even marc never came up with a term it just calls it "production, publication, distribution and manufacture". I have been struggling to come up with a term for a long time.

How about "action"?

Ray

---

From: melanieWacker [notifications@github.com] Sent: Wednesday, April 22, 2015 4:00 PM To: blunalucero/MODS-RDF Cc: Denenberg, Ray Subject: Re: [MODS-RDF] Superfluous Wrappers or Top Level Elements (#10)

Question: What should we name that new event superclass that is going to take the place of originInfo? If we just call it modsrdf:Event that seems a bit broad.

� Reply to this email directly or view it on GitHubhttps://github.com/blunalucero/MODS-RDF/issues/10#issuecomment-95319375.

[melanieWacker]

Thinking that "action" could potentially get interpreted to include other kinds of of actions, such as preservation action taken. The original "mods:originInfo" was actually not a bad solution as a name for this. Maybe "ResourceOrigin"? Or "Provider action"?

[raydAtLC]

How about "originationEvent"?

---

From: melanieWacker [notifications@github.com] Sent: Thursday, April 23, 2015 1:45 PM To: blunalucero/MODS-RDF Cc: Denenberg, Ray Subject: Re: [MODS-RDF] Superfluous Wrappers or Top Level Elements (#10)

Thinking that "action" could potentially get interpreted to include other kinds of of actions, such as preservation action taken. The original "mods:originInfo" was actually not a bad solution as a name for this. Maybe "ResourceOrigin"?

� Reply to this email directly or view it on GitHubhttps://github.com/blunalucero/MODS-RDF/issues/10#issuecomment-95667848.

[melanieWacker]

That sounds good.