Giter VIP home page Giter VIP logo

houndstooth's Introduction

Houndstooth

A meta-model based on Scooby Snacks and Dog Biscuits

Contributing

Before submitting a pull request, validate the YAML with yamllint:

$ yamllint m3.yml
m3.yml
  109:7     warning  comment not indented like content  (comments-indentation)
  122:4     warning  comment not indented like content  (comments-indentation)
  124:6     warning  comment not indented like content  (comments-indentation)

Tools

  • yamllint (gem install yamllint) - comannd line YAML validation
  • jsonschemalint - web-based tool for validating json against a JSON schema
  • YAML Converter - web-based tool for converting YAML to JSON
  • validate.rb - lightweight script to validate an m3 YAML specification against the JSON Schema (m3_json_schema.json); run with ruby validate.rb m3.yml

houndstooth's People

Contributors

acklose avatar arwenhutt avatar bess avatar chrissyrissmeyer avatar cjcolvar avatar dunn avatar jeremyf avatar jlhardes avatar no-reply avatar orangewolf avatar ruthtillman avatar shanalmoore avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

houndstooth's Issues

Tease apart the "available_on" into a joining data structure

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.

Use inheritance instead of key matching?

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.

Add IRIs for mappings

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.

update references to default branch

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.

Support per class controlled_values

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.