search

blunalucero / MODS-RDF

MODS RDF is an RDF ontology for MODS. As MODS is an XML schema for a bibliographic element set, MODS RDF is an expression of that element set in RDF.
7 stars 4 forks source link

Defining properties for roles #2

Open melanieWacker opened 10 years ago

melanieWacker commented 10 years ago

See Ray's e-mail from Nov. 8, 2013 for more background. Three ways defining properties for roles are being suggested:

  1. Discrete set of roles and define a property for each.
  2. Terms from a role vocabulary could serve as properties.
  3. A combined approach, where the group defines properties for the most commonly used roles, and when necessary to supply a role not included use the appropriate vocabulary term.
melanieWacker commented 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

mixterj commented 10 years ago

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.

melanieWacker commented 10 years ago

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

mjhan3 commented 10 years ago

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

melanieWacker commented 10 years ago

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.

raydAtLC commented 10 years ago

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

kefo commented 10 years ago

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.

mjhan3 commented 9 years ago

<?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">

Douleia esclavage et pratiques discursives dans l'athènes classique 
    <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>