Skip to content

Latest commit

 

History

History
86 lines (59 loc) · 3.71 KB

2020-05-20.dcap_zoom_call.md

File metadata and controls

86 lines (59 loc) · 3.71 KB
Raw

DCAP meeting Wednesday May 20, 2020

Time: 14:00 UTC

Zoom Join URL: https://us02web.zoom.us/j/84340370530?pwd=K1p3SHlsYy9XTmdQcHYvd1ZUSjkvdz09

HackMD agenda: https://hackmd.io/z4vzZVjBSkybhgxeLlSurA

Participants

  1. karen coyle
  2. Tom Baker
  3. Phil Barker
  4. John Huck
  5. Nishad Thalhath

Agenda

Minutes of previous meeting

Proposed

  1. Develop AP initially for RDF metadata, with the eventual determination if the template can be used with other metadata formats
  2. Create tests of the AP similar to the Wikidata instance, with examples, transformation code and validation

c.f. Phil's example

Minutes

  1. Group decided to focus first on APs for RDF, and to later determine if the result can be generalized to non-RDF metadata.
  2. Examples will be developed for: schema.org - Phil Wikidata - ? contentDM? - KC BIBFRAME - KC DataCite - John H

Some areas that need more discussion are:

  1. Where to put namespace columns and what to call those columns
  2. Should entity descriptions be on their own row? (Advantages: can annotate, can give cardinality)
  3. Can one designate properties as usable anywhere (aka: free-floaters)? (Idea: place them first before first entity)
  4. There is still the question of IDs for properties (KC will attempt an example)

Discussion

Abstract model strawman: "A profile can have one or more entities, each with one or more statements."

Naming and defining:

  • Profile_Entity

    • Definition strawman: "A thing or concept that will be described by the profile."
    • Is the entity described on its own row? Does it have cardinality?
    • Column label:
    • Also suggested:

  • Property

    • Definition strawman: "The previously defined data element that can be used to describe an aspect of the entity."
    • Column label:

  • Statement

    • Definition strawman: "The property and value constraints that describe an aspect of the entity."
    • Also suggested:

(Note to kc self: to what does the annotation refer? The entire row? Some element in the row?)

Minutes

Open Questions

  1. Will we want to define URIs for these properties? Do we prefer to use existing DC (or other) terms or AP-specific?
  2. How to define namespaces within a tabular format?
  3. How far do we want to take the value definitions? Include more, or leave to developers? What is the optimum "simple" for this? Would we want to include regex formulas in this column?
  4. Can valuetype be expanded to include pick lists, URI stems? Or do we limit to standard value types?
  5. Should the entity be on a separate row, or only on the row with properties? (advantages to separate: can include cardinality; can have an entity-specific annotation)
  6. How can we include constraints for "recommended" and "mandatory if applicable"?
  7. What transformations can we add to our prototypes?
  8. Should we specifically develop a "ShEx-friendly" version? e.g. https://github.com/johnsamuelwrites/dcap/blob/master/ShExStatements/shexstatements.ipynb

Resolved

  1. Can minimalist profile be the core of a more extensive profile template? (We seem to agree that it SHOULD.)
  2. Can the "simple" be used as is, or are more properties needed? (We are going with "as is" for now)
  3. How will we handle multiple values in a single cell (e.g. a pick list of string values)? ANSWER: For now using ShEx method of space between entries.