Open melanieWacker opened 10 years ago
See also Role Expressed as Vocabulary Member Development of a MODS RDF Ontology: Discussion Points Ray Denenberg, Library of Congress November 4, 2013 Discussion point 2.3
I prefer the first option. If we have an "all inclusive" list of object properties in the ontology, there is nothing to say that people could not integrate other object properties that define "roles" outside if MODS.
This MARC discussion paper contains information on how BIBFRAME deals with the issue of relationship designators (see point 5). It is currently being discussed on the BIBFRAME list: http://loc.gov/marc/mac/2014/2014-dp04.html
I am sure every one saw this already -- "The Joint Steering Committee for Development of RDA (JSC), Metadata Management Associates, and ALA Publishing (on behalf of the co-publishers of RDA) are pleased to announce that the RDA elements and relationship designators have been published in the Open Metadata Registry (OMR) as Resource Description Framework (RDF) element sets suitable for linked data and semantic Web applications." http://metadataregistry.org/schemaprop/list/schema_id/81.html
See also section 4 (Representing Roles) in the BIBFRAME Authorities draft specifications (7 March 2014): http://www.loc.gov/bibframe/docs/bibframe-authorities.html BIBFRAME is following "our" option two, relying on outside vocabularies. I like that approach since we would not have to determine which "roles" are important enough to be object properties.
Melanie – we had a serious discussion about this yesterday which is going to result in a slight change in the next draft of the BIBFRAME Authority spec.
The problem is that BIBFAME cannot just discard a role simply because there is no vocabulary term for it.
An example might be ‘former owner’:
http://www.loc.gov/standards/mods/modsrdf/examples/0009.xml http://www.loc.gov/standards/mods/modsrdf/examples/0009.xml
has role: ‘former owner’
The corresponding (LC) MODSRDF record:
http://www.loc.gov/standards/mods/modsrdf/examples/0009.rdf http://www.loc.gov/standards/mods/modsrdf/examples/0009.rdf
has this construct:
modsrdf:roleRelationship
modsrdf:RoleRelationship
<modsrdf:roleRelationshipRole>former owner.</modsrdf:roleRelationshipRole>
<modsrdf:roleRelationshipName rdf:resource="idname128418320" />
</modsrdf:RoleRelationship>
</modsrdf:roleRelationship
’roleRelationshipName’ points to the Authority.
What we think we are going to do in BIBFRAME is retain the role as property mechanism when there is a vocabulary term but when there isn’t, use a construct similar to the above (instead of roleRelationship, call it ‘relator’).
Thus:
bf:relator
bf:Relator
<bf:relatorRole>former owner.</bf:relatorRole>
<bf:relatorAgent rdf:nodeID="bnode-xyz"/>
/bf:Relator
/bf:relator
So this construct, bf:Relator, includes a role (string) and points to an Agent, thus relating the role to the agent..
BIBFRAME would stipulate that this construct should be used only when the role cannot be represented as a property using a vocabulary term.
So the question for us, for the MODSRDF ontology, do we want to discard role information when there is no vocabulary term? If not, I suggest we adopt this approach.
Ray
From: melanieWacker [mailto:notifications@github.com] Sent: Tuesday, April 08, 2014 3:10 PM To: blunalucero/MODS-RDF Subject: Re: [MODS-RDF] Defining properties for roles (#2)
See also section 4 (Representing Roles) in the BIBFRAME Authorities draft specifications (7 March 2014): http://www.loc.gov/bibframe/docs/bibframe-authorities.html BIBFRAME is following "our" option two, relying on outside vocabularies. I like that approach since we would not have to determine which "roles" are important enough to be object properties.
— Reply to this email directly or view it on GitHub https://github.com/blunalucero/MODS-RDF/issues/2#issuecomment-39888953 . https://github.com/notifications/beacon/4854536__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxMjYwMzQwMywiZGF0YSI6eyJpZCI6MjMwNjgzNTR9fQ==--cd7e271700b4d1d202d22cbcb6ed7791a4638fcb.gif
Let's be clear on one point: this is a transformation issue. Freshly created MODS/RDF (or whatever flavor RDF) should not be affected by this, or someone is doing something wrong.
So, since this is an issue that arises only when considering transformation [^1], I think the name and the unmatchable relationship should just be entered as a note on/for the resource. Perhaps add some special syntax to give the note some structure if that makes one feel better, but a "Relator" resource really isn't a "solution" to this problem. Yes, it captures the information so that it isn't lost, but it potentially creates tremendous overhead for what is, at the heart, bad data (or, as has been suggested elsewhere, 'anomalous' data).
A note - even one with a smidgen of structure - is a single triple. In this way one single triple is devoted to data a cataloger mangled. The proposed solution introduces at least three triples. Not necessarily a problem in the abstract, but what happens when this is applied millions of times?
Using a note to capture this information does not preclude associating, via a more abstract property, like relators:cre or relators:ctb, the Resource with an Agent responsible for the Resource. Doing it this way you have one pattern - yes, 1 - designed to associate Resources with Agents. The proposed solution introduces a second pattern. There's the regular way (Pattern 1) but, wait, sometimes, you never know when, there will be this other pattern (Pattern 2). And, since you never know when or where this other pattern is used, you'll have to perform an extra query each and every time you access a Resource. That - not to mention the extra triples - makes for a lot of overhead.
A transformation should do everything possible to take anomalous data and make something of it (incidentally, a transform could, and should, resolve the above to a relators code very easily, despite it being used as an example of poor data). But, if the transformation cannot manage this, we shouldn't enshrine this cruddy data forever in its own resource, which is the proposal.
In summation: Don't take the BIBFRAME route and create a Relator resource. If you are transforming data and cannot make a match, then use a generic relationship property, shove the anomalous data into a note, log that action, tell someone to fix it, carry on living, and bask in your data's improved query-ability. If it were important, it would have been entered correctly or codes would have been used, the data would have been quality checked, and, if necessary, corrected.
[^1]: One might be tempted to make a counter argument to this statement that goes something like "people will want to enter their own relationship so this flexibility is needed." This is the moment when those individuals need to create their own property, or petition to have common lists expanded.
<?xml version="1.0" encoding="UTF-8" ?> <modsCollection xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.loc.gov/mods/v3" xsi:schemaLocation="http://www.loc.gov/mods/v3 http://www.loc.gov/standards/mods/v3/mods-3-5.xsd"> <mods xmlns="http://www.loc.gov/mods/v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="3.5" xsi:schemaLocation="http://www.loc.gov/mods/v3 http://www.loc.gov/standards/mods/v3/mods-3-5.xsd">
<name type="personal" usage="primary" authorityURI="http://viaf.org" valueURI="http://viaf.org/viaf/7393715/">
</name>
<typeOfResource>text</typeOfResource>
<genre authority="marcgt">bibliography</genre>
<originInfo>
<place>
<placeTerm type="code" authority="marccountry">fr</placeTerm>
</place>
<place>
<placeTerm type="text">Paris</placeTerm>
</place>
<publisher>Belles Lettres</publisher>
<dateIssued>1980</dateIssued>
<issuance>monographic</issuance>
</originInfo>
<language>
<languageTerm authority="iso639-2b" type="code">fre</languageTerm>
</language>
<physicalDescription>
<form authority="marcform">print</form>
<extent>217 p. ; 24 cm.</extent>
</physicalDescription>
<note type="statement of responsibility" altRepGroup="00">Marie-Madeleine Mactoux.</note>
<subject authority="lcsh">
<topic authorityURI="http://id.loc.gov" valueURI="http://id.loc.gov/authorities/subjects/sh85123335"></topic>
</subject>
<subject authority="lcsh" authorityURI="http://id.loc.gov" valueURI="http://id.loc.gov/authorities/subjects/sh85123323">
<topic authorityURI="http://id.loc.gov" valueURI="http://id.loc.gov/authorities/subjects/sh85123314"></topic>
<geographic>Greece</geographic>
</subject>
<location>
<physicalLocation displayLabel="Institution Code">IU</physicalLocation>
<holdingSimple>
<copyInformation>
<subLocation>Oak Street Facility [request only]</subLocation>
<shelfLocator>326.938 M25D</shelfLocator>
<note displayLabel="Copy Number">1</note>
<note displayLabel="Barcode">30112059732039</note>
</copyInformation>
</holdingSimple>
</location>
<identifier type="isbn">225160250X</identifier>
<identifier type="oclc">ocm08276707</identifier>
<identifier type="uri" displayLabel="WorldCat Linked Data">http://www.worldcat.org/oclc/08276707</identifier>
<recordInfo>
<descriptionStandard>aacr</descriptionStandard>
<recordCreationDate encoding="marc">820326</recordCreationDate>
<recordChangeDate encoding="iso8601">20020415161257.0</recordChangeDate>
<recordIdentifier>314</recordIdentifier>
<recordOrigin>Converted from MARCXML to MODS version 3.5 using MARC21slim2MODS3-5.xsl
(Revision 1.96 2014/04/22)</recordOrigin>
</recordInfo>
</mods>
<mods
xmlns="http://www.loc.gov/mods/v3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
version="3.5"
xsi:schemaLocation="http://www.loc.gov/mods/v3 http://www.loc.gov/standards/mods/v3/mods-3-5.xsd">
<titleInfo>
<title>Martial et l'esclavage</title>
</titleInfo>
<typeOfResource>text</typeOfResource>
<genre authority="marcgt">bibliography</genre>
<originInfo>
<place>
<placeTerm type="code" authority="marccountry">fr</placeTerm>
</place>
<place>
<placeTerm type="text">Paris</placeTerm>
</place>
<publisher>Belles Lettres</publisher>
<dateIssued>1981</dateIssued>
<issuance>monographic</issuance>
</originInfo>
<language>
<languageTerm authority="iso639-2b" type="code">fre</languageTerm>
</language>
<physicalDescription>
<form authority="marcform">print</form>
<extent>241 p. : ill., map ; 24 cm.</extent>
</physicalDescription>
<note type="statement of responsibility" altRepGroup="00">M. Garrido-Hory.</note>
<subject authority="lcsh">
<topic authorityURI="http://id.loc.gov" valueURI="http://id.loc.gov/authorities/subjects/sh85123339"></topic>
</subject>
<subject authority="lcsh" authorityURI="http://id.loc.gov" valueURI="http://id.loc.gov/authorities/subjects/sh85123324">
<topic authorityURI="http://id.loc.gov" valueURI="http://id.loc.gov/authorities/subjects/sh85123314"></topic>
<geographic>Rome</geographic>
</subject>
<location>
<physicalLocation displayLabel="Institution Code">IU</physicalLocation>
<holdingSimple>
<copyInformation>
<subLocation>Main Stacks</subLocation>
<shelfLocator>C .44B46JLser.2 v.255-256</shelfLocator>
<note displayLabel="Copy Number">1</note>
<note displayLabel="Barcode">38888123170106</note>
</copyInformation>
</holdingSimple>
</location>
<location>
<physicalLocation displayLabel="Institution Code">IU</physicalLocation>
<holdingSimple>
<copyInformation><subLocation>Main Stacks</subLocation>
<shelfLocator>326.937 G193M</shelfLocator>
<note displayLabel="Copy Number">1</note>
<note displayLabel="Barcode">30112059731882</note>
</copyInformation>
</holdingSimple>
</location>
<identifier type="isbn">2251602550</identifier>
<identifier type="oclc">ocm08276772</identifier>
<identifier type="uri" displayLabel="WorldCat Linked Data">http://www.worldcat.org/oclc/08276772</identifier>
<recordInfo>
<descriptionStandard>aacr</descriptionStandard>
<recordCreationDate encoding="marc">820326</recordCreationDate>
<recordChangeDate encoding="iso8601">20020415161257.0</recordChangeDate>
<recordIdentifier>315</recordIdentifier>
<recordOrigin>Converted from MARCXML to MODS version 3.5 using MARC21slim2MODS3-5.xsl
(Revision 1.96 2014/04/22)</recordOrigin>
</recordInfo>
</mods>
See Ray's e-mail from Nov. 8, 2013 for more background. Three ways defining properties for roles are being suggested: