Skip to content

Latest commit

 

History

History
51 lines (36 loc) · 4.07 KB

20200317-minutes.md

File metadata and controls

51 lines (36 loc) · 4.07 KB

Metadata Templates Working Group Minutes

Tuesday, 2020/03/17

10:00 am ET

Attendees:

Terrell Russell, Jason Coposky, Kory Draughn, Dave Fellinger, Mike Conway, Deep Patel, Ton Smeele

Minutes

Status:

ONGOING: Atomic Metadata Operations API irods/irods#4808

GOAL: Build freestanding Metalnx -> MT API -> iRODS demo

TODO: Generate 3-4 CEDAR JSON schemas for holding/testing

TODO: Update the attribute in the AVU from $id to:

TODO: Generate first draft of Swagger MT-iRODS API

  • List overall available MT in the pool
  • List attached MTs on an object/collection
  • Attach/Apply MT to an object/collection as required/optional
  • Remove MT from an object/collection
  • Resolve instance of MT based on an object/collection JSON
  • Resolve json schema(s) that defines the metadata to be applied via template X to collection Y
  • POSSIBLE - Rasterize? Set of nested/attached schemas down into a single schema

CONSIDER: trigger on iRODS API PEPs rather than lower-level database PEPs

  • this will allow control/policy for both atomic and singular metadata edit attempts

DISCUSSION: microservices should maybe grow PEPs as well? Mostly concerned with authorization issues. Could be mitigated for now with the microservices calling server_api_call, thereby going back through the PEP machinery in the server.

DISCUSSION: additional requirement may include instances of JSON to be able to refer to their controlled vocabulary that defines the elements - use of 'rel/describedby' and 'href' within each property. CEDAR doesn't currently support this, but may as the standards come into focus.

  • { "$id": "http://example.com/myschema.json",
"$schema": "http://json-schema.org/schema#",
"type": "object",
"additionalProperties": false,
"properties": {
"links": {
"type": "array", "minItems": 1, "maxItems":
1,
"items": {
"type": "object",
"additionalProperties": false,
"required": [ "rel", "href" ],
"properties": {
"rel": { "const": "describedby" },
"href": { "const":
"http://example.com/myschema.json" }
}}},
"title": { "type": "string" },
"parameters": {
"type": "object",
"additionalProperties": false,
"properties": {
"size": { "type": "number" },
"readOnly": { "type": "boolean" }
}},
"authors": {
"type": "array",
"items": { "type": "string" }
},
"references": {
"type": "array",
"items": {
"type": "object",
"additionalProperties": false,
"properties": {
"title": { "type": "string" },
"doi": { "type": "string" }
}}}}}

  • {
"links": [
{
"rel": "describedby",
"href": "http://example.com/myschema.json",
}
],
"title": "Hello World!",
"parameters": {
"size": 42,
"readOnly": false
},
"authors": [
"Foo",
"Bar"
],
"references": [
{
"title": "The Rule Engine",
"doi": "1234.5678"
}
]
}

  • JSON Schema specifies that a metadata template reference can optionally be included in a JSON structure as a 
Linked Description Object (LDO) 5 through the linked data protocol using a ”describedby” relationship [7]. For the
 purpose of validation, we will require the LDO to be included in each namespace. As a result, when the JSON
 structure is converted to corresponding AVUs, the resulting set will always include AVU information with the LDO 
that provides a reference to the ruling metadata template for this namespace. This method ensures that the ruling
 metadata template for a namespace is registered with the iRODS object