---
# System prepended metadata

title: 'DC TAP meeting Thursday, November 24, 2022'
tags: [dctap meetings]

---

# DC TAP meeting Thursday, November 24, 2022

**Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09

**HackMD link:** https://hackmd.io/wi_ZmqFMRsCLrXA25b3JlQ

**Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20221124T15&p1=%3A&ah=1))

## Participants

* John, Phil, Tom, Karen

###### tags: `dctap meetings` 

## Agenda

From Oct. 27 meeting: add to primer:

Add to primer: "can differ from label in underlying vocabulary"
KC to add - DONE

Note definition of valueNodeType in Primer
KC copy over from vocabulary - DONE

"Documents in this Project" - add to each document. Point to github?
https://hackmd.io/zxDR8FazSCKx6X_V6DK28w?both
KC - add to each

**Vocabulary document**

* [Document draft](https://hackmd.io/bwmOpD-7TH2EcQVg4r9QYQ?view) Draft has been re-ordered
* [Diagrams by Kc and Phil](https://docs.google.com/presentation/d/1KSv_807T8OtceZIJBHnbpy_0vwUMJg4KoYxplmAl5z0/edit#slide=id.g199b2684445_0_0)
* [Diagrams from Tom](https://github.com/dcmi/dctap/blob/main/media/2013Sep11W3CWorkshop/2013-09-11.rdfvalid_workshop_dcam.pdf) and [Email](https://lists.dublincore.org/pipermail/application-profiles-ig/2022-November/000718.html)
* Is title ok? We talk about "elements" in the document

Discussion of vocab document:

kc made two categories: concepts v elements

The table:
* kc reduced to structure, cardinality, component

Cardinality: 
ok

Diagrams:
* default shape along with actual shape. Is that too confusing? 
    * Phil - there can only be one default shape
    * kc - default shape is not named in the TAP
    * Phil - should diagrams say "default shape" and "named shape"
    * John - do we have examples with both a default and a named shape?
    * kc - there are properties before the first shape then those are outside the first shape and become a default. Everything that follows belongs to the shape above it
    * phil - we haven't discussed what is the scope of statement templates that are in a preceding default shape. Could those relate to the property wherever it occurs? e.g. sdo:name that is used everywhere
    * tom - can of worms. model doesn't have way to decide what in metadata gets evaluated. like shex shapemap. Also, shex has 'start shape'. 
    * phil - implementations will do what makes sense to them. could be that a property in default shape relates to use of that property in all shapes
    * kc - want to discourage the combination of default and named shapes?
    * john - what does dctap program do?
    * phil - creates shape named 'default'
    * tom - like the bnode of shapes
    * phil - if applies to all instances in the TAP can be efficient - all sdo:name are langstring. 
    * tom - this is very implementation specific
    * DECISION **discourage this** just show the shapes and the default in separate diagrams

Cardinality of default
* john - in terms of cardinality, does this mean there is always a shape?
* kc - no shapeID or shapeLabel in the TAP; assigning default shape happens outside of DCTAP in implementation
*  e.g. oai-pmh dublin core

Cardinality of shapes
* table did have 
* john: should be zero or one in table because you may not have a shapeID because you do not have a shape
* phil: if no shape id you still have a default shape, but it has no shapeID
* kc: default shape is what happens in python program; it is not in the TAP

ACTION: Change component in table to element

phil: reverse the order of the columns, so element comes before cardinality and it is more clear that cardinality applies to element

tom: or have two tables; shape and statement template. word 'component' could disappear

kc: we decided structure would be shown in diagram, not in table. need two diagrams - one with shapes, one without. Would be hard to get cardinality into diagram, but if not in table could be in definitions.

kc: do we want a uml diagram with all of the elements?

tom: doesn't show how shapes link. Could do in a diagram.

kc: that requires more info in the diagram. And hard to do in markdown in the primer. we may need to use images instead of markdown tables

phil: say what the components are - DONE

phil: delete word components in structure column; change structure column to 'components'. Move structures to last column, with value on every row. - DONE (PHIL)


