samvera-labs / houndstooth Goto Github PK

This is related to #21

When I'm thinking about iterating over the m3 data to build a dynamic form, I'd be expecting to iterate on something like:

{
  "class": "genericWork",
  "properties": [
    {
      "property": "creator",
      "overrides": {
        "display_label": "My Custom Creator",
        "controlled_vocabulary_uri": "https://only.creatives.net/creators"
      }
    }
  ]
}

When I encounter a "property", I would retrieve the property's m3 data, and merge that with the overrides. I would favor overrides.

Join Table between Class and Property

I also believe, from a structural standpoint, you may want to consider a "joining" data structure for class and property. (I'm thinking in terms of databases and how I would structure these in SQL) The "available_on" attribute of a "property" feels very funny. The "joining" data structure would also provide guidance on sequence of rendering. And would make it trivial to add the controlled vocabularies.

class_properties:
  class: genericWork
  properties:
  - property: title
  - property: creator

Building Further

It may make sense to further break out controlled vocabularies as their own "table", then you could repurpose those controlled vocabularies across different classes/properties.

It is feasible that a field in one work would use a different controlled vocabulary source, for example a Journal Article work might use the crossref journal lookup service, but the same (part_of) field in a Book model would not.

The default branch of this repository has been renamed from master to main per the Branch Renaming WG; any remaining references to the previous name should be updated as they are found.

Right now mappings are defined like :—

mappings:
    oai_dc:
        name: "OAI/DC"

I would like to add an iri (or uri) property in addition to name for mappings.

Motivation

Our API supports multiple mappings via a profile media type parameter, which must be an IRI. For example, we use the following Accept: header to request OAI/DC content:

Accept: application/ld+json; profile="tag:surfliner.gitlab.io,2022:api/oai_dc"

It would be nice if Houndstooth supported looking up metadata mappings by IRI, so that we wouldn’t have to make assumptions in our application about which mapping tag:surfliner.gitlab.io,2022:api/oai_dc refers to.

in, e.g, https://github.com/samvera-labs/houndstooth/blob/main/examples/UCSD.yaml we have definitions like:

properties: # add to spec?
  "agent:contributor": # I think the quotes here are causing problems - which might be the colon in the property names is an issue...
    display_label: "Contributor"
    definition: "A person or organization responsible for making contributions to the resource."
    usage_guidelines: # I think the formatting of this list is wrong, and I need to either put everything in quotes, or turn it into a list of key/value pairs
      General: "Use as the broadest possible role, i.e. when lacking specific information on an agent's role, or the role is unclear or unknown. If a more specific role is available, prefer that, e.g. editor, compiler, illustrator."
      RDCP: "Use for institutions, centers in addition to individuals that contribute to a resource (e.g. SIO, CAICE)"
      "DLDP/SCA": "null"
      Music: "null"
      CLR: "null"

it's not clear to me in this case what "General", "RDCP", etc... represent, in terms of M3 abstractions. in other cases we have:

  usage_guidelines: 
      default: "Record in lastname, firstname order."
      Geospatial: "some other value"

where it's more clear that "Geospatial" is a class. but i'm still concerned that these examples involve a matching step after parsing to decide which parts of a property definition apply to which objects.

i'd propose an alternative:

properties: # add to spec?
  agent_contributor:
    display_label: "Contributor"
    available_on:
      - General
    definition: "A person or organization responsible for making contributions to the resource."
    usage_guidelines: "Use as the broadest possible role, i.e. when lacking specific information on an agent's role, or the role is unclear or unknown. If a more specific role is available, prefer that, e.g. editor, compiler, illustrator."

  "agent:contributor:geospatial":
    <<: *agent_contributor
    available_on:
      - Geospatial    
    usage_guidelines:  "some other value"

this gives a general solution for any case where a given property needs to be overridden per class. and avoids introducing a separate abstraction for applying these overrides. on the implementation side, it has the benefit that you can use base YAML parsing to determine what properties apply to which classes. once you've done this, you can apply them wholesale without the need to filter contextually.

Rather than listing all MARC relator predicates in metadata model, could we point to another configuration file that lists only the relators currently in use? How could we do that?