New Relators Module (Looking for input)

[joseph_anderson]

Hello folks,

Wanted to check if there’s any interest in the community in a module I’ve been developing at our institution. This module, Relators, adds functionality so that you can specify relators/roles for the DC contributor field, so that for a given contributor, you can say that they were the ‘Author’, ‘Artist’, or ‘Designer’, etc., any of the relators listed on the LOC Linked Data service for MARC relators. The advantage of something like this is that you can keep all the agents in one field and the relator info is stored separately and doesn’t interfere with search and collocation. For example, if you use a module like Metadata Browse and had one item with contributor Chanel, Coco (Designer) and another Chanel, Coco (Author), it will still match them up because the relator data is not part of the label or the value. I’ve developed it enough so that it works more or less for our own purposes, but wanted to see if there was any additional interest that would warrant developing further for a public release.

You can check it out here. It should work pretty straightforwardly, but again there’s room for development:

Thanks for any input,

Joseph Anderson

[jflatnes]

Out of curiosity, how are you storing the “relator” information? It seems like it’s probably not stored with the values because of how this interacts with other existing things… is it just a join to a separate table?

[joseph_anderson]

@jflatnes, yeah that was somewhat tricky to figure out. I took guidance from numeric data types module. I created a new relator entity, which is linked to the values in a roundabout way. From what I understand, it’s not actually possible to directly join to the value itself, so what I ended up doing is joining it to the resource and property and then duplicating in the relator table the actual components of the value (value, uri, and valueResource). Then it just matches those up whenever it needs to be output. Duplicating those values is probably not the most efficient thing but it’s only occurring for a very small percentage of the values, so it didn’t seem like a very terrible way of going about it.

I couldn’t really figure out another way to achieve this that wouldn’t involve altering the core code. Anyhow thanks for checking it out!

[donellop]

Hi Joseph, this module looks like it could be very useful for our project. I’m excited to read about this. We had opted for creating different fields for each contribution role, but it makes the resource templates very long and unwieldy. I look forward to trying your module out shortly.

[joseph_anderson]

@donellop, thanks, and please don’t hesitate to let me know if you see anything buggy or any ideas to improve.

[donellop]

Hi @joseph_anderson, I installed the module. I am just starting out working with modules so any hurdles I encountered may be due to inexperience.

When I first uploaded the module I got the following warning in the Modules section instead of the Install button:

Error: invalid Module.php file

Changing the module name to Relators instead of Relators-main resolved it, though.

I added dc:contributor to my resource template and then tried to use the property in an item but I didn’t see the dropdown for all the relator terms. Does the field need to be set up with a specific data type in order to work? I tried it with types resource item, text and with no type specified.

Thanks!

[joseph_anderson]

@donellop Hmm, not sure what’s going on there. Yes, you would need to rename the directory to just Relators rather than Relators-main. Github adds the name of the branch in there for downloads. But after that it should work. I just tried it on a fresh install, and used it with a resource template that includes contributor, and it was working ok for me. It should work with any of the core data types: text, uri, or omeka resource.
The only thing I can think of without taking a closer look is that the module uses javascript to add the drop-down and somehow that’s being blocked on your end.

I can do a quick video meeting with you if you’d like. I’m curious what’s preventing it from working.

[luca.g]

Hello,

is this something I should check out for my own case (see MARC records, Dublin Core and MARC relator)? It sounds interesting.

[joseph_anderson]

@luca.g, this module could possibly help with your situation, but you would need to do some data massaging to transform your marcxml data into JSON-LD for import via the omeka-s rest api. The module is set up to be able to ingest relators through the api, so a brief sample of that as JSON-LD would:

{
  "dcterms:title": [
    {
      "type": "literal",
      "property_id": 1,
      "property_label": "Title",
      "@value": "Hatted Head with Lipstick for Vogue cover"
    }
  ],
  "dcterms:description": [
    {
      "type": "literal",
      "property_id": 4,
      "property_label": "Description",
      "@value": "Cropped figure in veiled hat holding lipstick; Color: brush, watercolor and gouache; Signed \"Vogue\" \"To Mrs. Taylor evening Paris.\" Signed ll; Client Vogue Cover Sketch"
    }
  ],
  "dcterms:contributor": [
    {
      "type": "uri",
      "property_id": 6,
      "property_label": "Contributor",
      "is_public": true,
      "@id": "http://id.loc.gov/authorities/names/n84095441",
      "o:label": "Bérard, Christian, 1902-1949",
      "o-module-relators:relators": [
        {
          "type": "uri",
          "@id": "http://id.loc.gov/vocabulary/relators/abr",
          "o:label": "Abridger"
        },
        {
          "type": "uri",
          "@id": "http://id.loc.gov/vocabulary/relators/dgg"
        }
      ]
    },
    {
      "type": "resource",
      "property_id": 6,
      "property_label": "Contributor",
      "is_public": true,
      "value_resource_id": 1033,
      "o-module-relators:relators": [
        {
          "type": "literal",
          "@value": "Abridger"
        },
        {
          "type": "literal",
          "@value": "Degree granting institution"
        }
      ]
    }
  ]
}

In the example, you can see that the relators are included as a subproperty (“o-module-relators:relators”) of the contributor property. You can express it as a uri or a literal, with or without the actual relator term. The module will look up the preferred term if you only provide the uri, and vice versa, if you only include the term it will grab the uri.

So you would have to transform your marc into dublin core and then parse out the relator terms and include them as subproperties. That’s totally doable, but could be a little painstaking.

-Joseph

[luca.g]

Thank you @joseph_anderson. I was thinking of exporting the MARCXML to csv (using MarcEdit) and then importing the .csv into Omeka using https://omeka.org/s/modules/CSVImport/ . I think that would be doable and less painstaking. Do you seen any drawbacks to this approach?

[joseph_anderson]

@luca.g, in general, that might be much easier in your situation, but the module that I created isn’t currently functional with csv import. That’s something I could look into in the future, but I didn’t work on it because in our use case we’re ingesting mostly through the api.

Basically, the challenge with using the csv import with this relator module is that it’s hard to indicate with everything else going on, what data in the csv cell is the relator versus the value or the label or the uri. You would have to encode it in someway and I worry that could get messy and hacky.