;
83 | rdfs:label "hasValue" .
84 |
85 |
86 |
--------------------------------------------------------------------------------
/dspDiagram2.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/dcmi/dcap/a3a3f0dcda84179e9624df3a75b9277bd8d00cb7/dspDiagram2.jpg
--------------------------------------------------------------------------------
/examples/ex3.yaml:
--------------------------------------------------------------------------------
1 | %YAML 1.1
2 | ---
3 | value:
4 |
5 | - &value_literal_3_250
6 | valueID: value_literal_3_250
7 | dataType: literal
8 | minLength: 3
9 | maxLength: 250
10 |
11 | - &value2
12 | valueID: value2
13 | dataType: literal
14 |
15 | - &value3
16 | valueID: value3
17 | dataType: xsd:mbox
18 |
19 | statement:
20 |
21 | - &title
22 | statementID: title
23 | displayName: Title
24 | value : *value_literal_3_250
25 |
26 | - &name
27 | statementID: name
28 | displayName: Name
29 | value: *value2
30 |
31 | - &homepage
32 | statementID: homepage
33 | displayName: Homepage
34 | value: *value3
35 |
36 | description:
37 |
38 | - &book
39 | descID: book
40 | displayName: Book
41 | statements:
42 | - << : *title
43 | minOccur : 1
44 | maxOccur : 1
45 |
46 | - &creator
47 | descID: creator
48 | displayName: Creator
49 | statements:
50 | - << : *name
51 | minOccur : 1
52 | maxOccur : -1
53 | - << : *homepage
54 | minOccur : 0
55 | maxOccur : 1
56 |
57 | descriptionSet:
58 |
59 | descSetID: 123
60 | descriptions : [*book, *creator]
61 |
--------------------------------------------------------------------------------
/meetings/2019/hackDay_DCMI2019.md:
--------------------------------------------------------------------------------
1 | # AP Hack
2 |
3 | Google spreadsheet: https://docs.google.com/spreadsheets/d/1Dvda7Sqa3eZdz44BWNtUWjJ2CrJeNlHvLCHbPOro7Js/edit#gid=0
4 |
5 | Stefanie's data:
6 |
7 | http://asch.wiki.gwdg.de/index.php/ASCH_Model
8 |
9 | Item data:
10 |
11 | http://asch.wiki.gwdg.de/index.php/Item_DSP
12 |
13 | Tom's template:
14 |
15 | https://github.com/dcmi/dcap/tree/master/template_tom
16 |
17 |
18 | Data so far:
19 |
20 | Profile
21 | entity1
22 | property: dct:title
23 | valueKind: xsd:literal
24 | minOccur: 1
25 | maxOccur: 1
26 | property: dct:date
27 | minOccur: 1
28 | maxOccur: 1
29 | valueKind: xsd:year
30 | property: dct:creator
31 | valueKind: entity2
32 | entity2
33 | property: foaf:name
34 | valueKind: xsd:literal
35 | minOccur : 1
36 | maxOccur : -1
37 | property: foaf:homepage
38 | valueKind: xsd:mbox
39 | minOccur : 0
40 | maxOccur : 1
41 | entity3
42 | property: dct:date
43 | minOccur: 1
44 | maxOccur: 1
45 | valueKind: xsd:monthDay
46 | property: xxx:yyy
47 | valueKind: xsd:literal
48 | minOccur: 1
49 | maxOccur: 1
50 |
51 |
52 |
53 | "proof of concept" program (Ruby):
54 | https://gist.github.com/masao/08a14cb14a005ca26e183a7b9b410f07
55 | - Excel template to SHACL (RDF/Turtle) format.
56 | - Using ruby-roo library: https://github.com/roo-rb/roo
57 |
58 | ### Authoring & Publishing
59 |
60 | https://github.com/nishad/dc2019-hack-day/
61 | https://github.com/nishad/ap-gh-example
62 |
--------------------------------------------------------------------------------
/meetings/2020/2020-03-03.dcap_zoom_call.md:
--------------------------------------------------------------------------------
1 | # DCAP meeting March 3, 2020
2 |
3 | Time: [15:00 UTC](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DCAP+meeting&iso=20200303T15&p1=1440)
4 |
5 | Zoom Join URL: https://zoom.us/j/630190288
6 |
7 | HackMD agenda: https://hackmd.io/pTAlXlcTQFmyrCutEhisCg?both
8 |
9 | ## Participants
10 |
11 | 1. Karen
12 | 2. Tom
13 | 3. John john.huck@ualberta.ca
14 | 4. Alexis alexiskm@uw.edu
15 |
16 | Regrets: Stuart, Mariana
17 |
18 | ## Agenda
19 |
20 | ### Review minimalist profile(s)
21 |
22 | 1. https://github.com/dcmi/dcap/tree/master/prototypes/simpleFromHackathon
23 | 2. https://github.com/dcmi/dcap/tree/master/prototypes/wikidata_painting
24 |
25 | RESOLVED: That the most minimal profile could consist of a list of properties.
26 | Because we resolved earlier that URIs are not required, a separate property label" would not be required. (We questioned this later.)
27 |
28 | ACTION: To develop definitions for the elements of the simple profile model (as a document in Github). (Tom will give John and Alexis access to the repository.) Karen will create initial document.
29 |
30 | John: If a profile has just a list of properties, how is it different from a vocabulary? (Tom will ask this on the list.)
31 |
32 | ### Comparison
33 |
34 | **Elements**
35 |
36 | |[no 1]( https://github.com/dcmi/dcap/tree/master/prototypes/simpleFromHackathon) | [no 2](https://github.com/dcmi/dcap/blob/master/prototypes/wikidata_painting/E130b.csv)
37 | | --- | ---
38 | |Entity_name|Entity_name|
39 | |Entity_label|Entity_label|
40 | |Statement_ID| |
41 | |Property|Property|
42 | |Property_Label|Property_label|
43 | |Cardinality|Mand|
44 | ||Repeat|
45 | ||Value|
46 | Value_type|Value_type|
47 | Annotation|Annotation|
48 |
49 | **Simplest**
50 | This is just a list of properties with optional labels
51 | |element|
52 | |----|
53 | |Property|
54 | |Property_Label
55 |
56 | **Simpler**
57 | This is for a profile that does not define entities, e.g. the profile is for a single entity. See some examples done for [ContentDM metadata](https://github.com/dcmi/dcap/wiki/Related-Projects#contentdm).
58 | |element|
59 | |---|
60 | |Property|
61 | |Property_Label|
62 | |Mand|
63 | |Repeat|
64 | |Value|
65 | |Value_type|Value_type|
66 | |Annotation|Annotation|
67 |
68 |
69 | ### Questions
70 |
71 | 1. What is the simplest that a profile can be and still be a profile?
72 | 2. Can minimalist profile be the core of a more extensive profile template?
73 | 3. Can the "simple" be used as is, or are more properties needed?
74 | 5. Will we want to define URIs for these properties? Do we prefer to use existing DC (or other) terms or AP-specific?
75 | 6. How to define namespaces within a tabular format?
76 | 7. How far do we want to take the value definitions? Include more, or leave to developers? What is the optimum "simple" for this?
77 | 8. Can value_type be expanded to include pick lists, URI stems? Or do we limit to standard value types?
78 | 9. What transformations can we add to our prototypes?
79 | 11. Should we specifically develop a "ShEx-friendly" version? e.g. https://github.com/johnsamuelwrites/dcap/blob/master/ShExStatements/shexstatements.ipynb
80 |
81 | ### Resolved
82 |
83 | 1. Shall we complete this minimalist profile? RESOLVED: YES (Feb 18)
84 | 2. Do properties have to be URIs? (RESOLVED: no (Feb 18))
85 | 3. RESOLVED: Profile can be less than simple template (entities, properties, values).
86 |
87 |
--------------------------------------------------------------------------------
/meetings/2020/2020-05-06.dcap_zoom_call.md:
--------------------------------------------------------------------------------
1 |
2 | # DCAP meeting Wednesday May 6, 2020
3 |
4 | Time: [14:00 UTC](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DCAP+May+6&iso=20200506T14&p1=1440&ah=1&am=30)
5 |
6 | Zoom Join URL: https://us02web.zoom.us/j/83699408597?pwd=OEpuR2xKYzZRNnd5cjhFcG95UENtdz09
7 |
8 | HackMD agenda: https://hackmd.io/33dG6BttQ8q3H6YFH4G5tw
9 |
10 | ## Participants
11 |
12 | 1. Karen Coyle
13 | 2. Tom Baker
14 | 3. Ben Riesenberg
15 | 4. Nishad Thalhath
16 |
17 | ## Agenda
18 |
19 | ### Minutes of [previous meeting](https://github.com/dcmi/dcap/blob/master/meetings/2020/202-04-22.dcap_zoom_call.md)
20 |
21 | ### Discussion
22 |
23 | Abstract model strawman:
24 | "A profile can have one or more *entities*, each with one or more *statements*."
25 |
26 | Naming and defining:
27 | * [Profile_Entity](https://github.com/dcmi/dcap/issues/60)
28 | * Definition strawman: "A thing or concept that will be described by the profile."
29 | * Is the entity described on its own row? Does it have cardinality?
30 | * Column label:
31 | * [Property](https://github.com/dcmi/dcap/issues/59)
32 | * Definition strawman: "The previously defined data element that can be used to describe an aspect of the entity."
33 | * Column label:
34 | * [Statement](https://github.com/dcmi/dcap/issues/59#issuecomment-623471657)
35 | * Definition strawman: "The property and value constraints that describe an aspect of the entity."
36 |
37 |
38 | (Note to kc self: to what does the annotation refer? The entire row? Some element in the row?)
39 |
40 | ## Minutes
41 |
42 | We looked at issue #60 in an attempt to define the term and name the first column of the template. Tom favored "entity shape ID". Nishad hoped that we could find something "non-conflicting". Ben and Karen felt that "shape" was too RDF-y and was not in general use. One option was to add "profile" to the column name, like "entity profile" since the thing being created is a profile.
43 |
44 | We also talked about the term "template". Nishad described the template as being like the cookie cutter, whereas what we are trying to define is the nature of the cookie batter, which will eventually be shaped by a cookie cutter/template.
45 |
46 | Ben advocated for finding a unifying terminology for the columns, such as adding "profile x" or "x profile" to show that they are part of a coherent unit. This could address Phil's issue that we want it to be clear that this is not about the instance data.
47 |
48 | If adding "profile" to column names is too long we can abbreviate them.
49 |
50 | Is the entity just a grouping of statements, or is it a thing in the metadata? What will connect the metadata and the profile? Nishad: the entity is a thing, and the profile connects things to things.
51 |
52 | Nishad: not just a list, the profile *explains*, which is more than a shape. Annotation has a key role in a profile because it makes it an explanation of usage. A shape is a constrainer, not an explainer.
53 |
54 | Tom: turn this into a proposal and see what counter-proposals are offered.
55 | ACTION: Tom will provide a proposal in a document to start this.
56 |
57 | ### Open Questions
58 |
59 | 1. Can minimalist profile be the core of a more extensive profile template? (We seem to agree that it SHOULD.)
60 | 3. Can the "simple" be used as is, or are more properties needed? (Have we decided "as is"?)
61 | 5. Will we want to define URIs for these properties? Do we prefer to use existing DC (or other) terms or AP-specific?
62 | 6. How to define namespaces within a tabular format?
63 | 7. 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?
64 | 8. How will we handle multiple values in a single cell (e.g. a pick list of string values)?
65 | 9. Can valuetype be expanded to include pick lists, URI stems? Or do we limit to standard value types?
66 | 10. How can we include constraints for "recommended" and "mandatory if applicable"?
67 | 11. What transformations can we add to our prototypes?
68 | 12. Should we specifically develop a "ShEx-friendly" version? e.g. https://github.com/johnsamuelwrites/dcap/blob/master/ShExStatements/shexstatements.ipynb
69 |
70 |
--------------------------------------------------------------------------------
/meetings/2020/2020-05-20.dcap_zoom_call.md:
--------------------------------------------------------------------------------
1 |
2 | # DCAP meeting Wednesday May 20, 2020
3 |
4 | Time: [14:00 UTC](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DCAP+May+20&iso=20200520T14&p1=1440&ah=1&am=30)
5 |
6 | Zoom Join URL: https://us02web.zoom.us/j/84340370530?pwd=K1p3SHlsYy9XTmdQcHYvd1ZUSjkvdz09
7 |
8 | HackMD agenda: https://hackmd.io/z4vzZVjBSkybhgxeLlSurA
9 |
10 | ## Participants
11 |
12 | 1. karen coyle
13 | 2. Tom Baker
14 | 3. Phil Barker
15 | 4. John Huck
16 | 5. Nishad Thalhath
17 |
18 |
19 | ## Agenda
20 |
21 | ### Minutes of [previous meeting](https://github.com/dcmi/dcap/blob/master/meetings/2020/202-05-06.dcap_zoom_call.md)
22 |
23 | ### Proposed
24 | 1. Develop AP initially for RDF metadata, with the eventual determination if the template can be used with other metadata formats
25 | 2. Create tests of the AP similar to the Wikidata instance, with examples, transformation code and validation
26 |
27 | c.f. [Phil's example](https://github.com/dcmi/dcap/blob/master/prototypes/bookclub/ap.csv)
28 |
29 | ### Minutes
30 |
31 | 1. Group decided to focus first on APs for RDF, and to later determine if the result can be generalized to non-RDF metadata.
32 | 2. Examples will be developed for:
33 | schema.org - Phil
34 | Wikidata - ?
35 | contentDM? - KC
36 | BIBFRAME - KC
37 | DataCite - John H
38 |
39 | Some areas that need more discussion are:
40 |
41 | 1. Where to put namespace columns and what to call those columns
42 | 2. Should entity descriptions be on their own row? (Advantages: can annotate, can give cardinality)
43 | 3. Can one designate properties as usable anywhere (aka: free-floaters)? (Idea: place them first before first entity)
44 | 4. There is still the question of IDs for properties (KC will attempt an example)
45 |
46 | ### Discussion
47 |
48 | Abstract model strawman:
49 | "A profile can have one or more *entities*, each with one or more *statements*."
50 |
51 | Naming and defining:
52 | * [Profile_Entity](https://github.com/dcmi/dcap/issues/60)
53 | * Definition strawman: "A thing or concept that will be described by the profile."
54 | * Is the entity described on its own row? Does it have cardinality?
55 | * Column label:
56 | * Also suggested:
57 |
58 | * [Property](https://github.com/dcmi/dcap/issues/59)
59 | * Definition strawman: "The previously defined data element that can be used to describe an aspect of the entity."
60 | * Column label:
61 | * [Statement](https://github.com/dcmi/dcap/issues/59#issuecomment-623471657)
62 | * Definition strawman: "The property and value constraints that describe an aspect of the entity."
63 | * Also suggested:
64 |
65 | (Note to kc self: to what does the annotation refer? The entire row? Some element in the row?)
66 |
67 | ### Minutes
68 |
69 | ### Open Questions
70 |
71 | 1. Will we want to define URIs for these properties? Do we prefer to use existing DC (or other) terms or AP-specific?
72 | 6. How to define namespaces within a tabular format?
73 | 7. 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?
74 | 9. Can valuetype be expanded to include pick lists, URI stems? Or do we limit to standard value types?
75 | 10. 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)
76 | 11. How can we include constraints for "recommended" and "mandatory if applicable"?
77 | 12. What transformations can we add to our prototypes?
78 | 13. Should we specifically develop a "ShEx-friendly" version? e.g. https://github.com/johnsamuelwrites/dcap/blob/master/ShExStatements/shexstatements.ipynb
79 |
80 | ### Resolved
81 |
82 | 1. Can minimalist profile be the core of a more extensive profile template? (We seem to agree that it SHOULD.)
83 | 2. Can the "simple" be used as is, or are more properties needed? (We are going with "as is" for now)
84 | 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.
85 |
86 |
87 |
--------------------------------------------------------------------------------
/meetings/2021/2021-01-20.dcap_zoom_call.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting January 20, 2021
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/88331879263?pwd=ZFBlUFRtbEpyaEVRbVhVRXY3cEFlZz09
4 |
5 | **HackMD link:** https://hackmd.io/X3RyLtO7QB-3RKHXOy4zRQ
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20210106T15&p1=%3A&ah=1))
8 |
9 |
10 | ### [Resolutions from previous discussions](https://hackmd.io/tjFOwoqqTIid4jtfmVzkLg)
11 |
12 | ## Participants
13 | *
14 |
15 | ## Agenda
16 |
17 | Confirm:
18 | * [#4](https://github.com/dcmi/dctap/issues/4) Multiple values in a cell
19 | * See [draft](https://github.com/dcmi/dctap/issues/4#issuecomment-756963132)
20 | * [#5](https://github.com/dcmi/dctap/issues/5) Value constraints list
21 | * See [draft](https://github.com/dcmi/dctap/issues/5#issuecomment-756189578)
22 |
23 | Next issues:
24 | * [#7](https://github.com/dcmi/dctap/issues/7) Boolean values
25 | * [#9](https://github.com/dcmi/dctap/issues/9) Default cardinality
26 | * [#8](https://github.com/dcmi/dctap/issues/8) Open/Closed
27 |
--------------------------------------------------------------------------------
/meetings/2021/2021-03-03.dcap_zoom_call.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting March 3, 2021
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/82221447836?pwd=VHQxa3dzeFNhL2RzVnF3cmNOb0EwQT09
4 |
5 | **HackMD link:** https://hackmd.io/6KS6sd5UQPGQ6GbMCn0a4A
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20210106T15&p1=%3A&ah=1))
8 |
9 |
10 | ### [Resolutions from previous discussions](https://hackmd.io/tjFOwoqqTIid4jtfmVzkLg)
11 |
12 | ## Participants
13 | * Tom Baker
14 | * Phil Barker
15 | * John Huck
16 | * Ben Riesenberg
17 | * Karen Coyle
18 | * Nishad Thalhath
19 |
20 | ## Agenda
21 |
22 | * Review namespace section in [primer](https://github.com/dcmi/dctap/blob/main/TAPprimer.md)
23 | * Comments on vocabulary by J Littman: LoC test of TAP: https://github.com/LD4P/dctap
24 | https://github.com/dcmi/dctap/issues/12
25 | https://github.com/dcmi/dctap/issues/13 https://github.com/dcmi/dctap/issues/14
26 | * Decide beta roll-out actions
27 |
28 | ## Decisions
29 |
30 | For issue #12, kc has responded:
31 | https://github.com/dcmi/dctap/issues/12#issuecomment-791597662
32 |
33 | For issue #13, we agreed that multiple value shapes are ok. Information about properties that can take multiple values will be added to the documentation. (Note: it seems that this fits best into the primer, because it may confuse even more the cardinality in the vocabulary document which refers to the TAP properties not their values)
34 |
35 | For issue #14, most felt that ordering may be out of scope. However, there are two ordering aspects: ordering of properties and ordering of values (objects of a property). For the latter, the table can only indicate that values must be ordered. This triggers the use of an array or a list (depending on the programming language or data schema). This could be handled with a single column with a binary value: ordered, not ordered. Ordering the properties themselves may be more complex. Within a shape, properties could be given an order number, but the question is whether shapes themselves need to be ordered. This is unresolved.
36 |
--------------------------------------------------------------------------------
/meetings/2021/2021-03-17.dcap_zoom_call.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting March 17, 2021
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/82221447836?pwd=VHQxa3dzeFNhL2RzVnF3cmNOb0EwQT09
4 |
5 | **HackMD link:** https://hackmd.io/KD3C9r6PQBWSLM84njYNMg
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20210317T15&p1=%3A&ah=1))
8 |
9 |
10 | ### [Resolutions from previous discussions](https://hackmd.io/tjFOwoqqTIid4jtfmVzkLg)
11 |
12 | ## Participants
13 | *
14 |
15 | ## Announcements
16 | * Poster presentation at [https://2021.code4lib.org/](https://) on March 23. Poster images in our repo: https://github.com/dcmi/dctap/tree/main/media/code4lib2021
17 |
18 | ## Agenda
19 |
20 | * Review [primer](https://hackmd.io/rwWTUC0xRA2X8xEsfPS_Cw) document (in Hackmd) and make comments
21 | * Do we need other documents? (e.g. an overall explanation of profiles, of the project ... ?)
22 | * Decide beta roll-out actions
23 |
--------------------------------------------------------------------------------
/meetings/2021/2021-03-31.dcap_zoom_call.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting March 31, 2021
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/k7TsgsfCSSGEWm9wm3BgGQ
6 |
7 | **Time:** 14:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20210331T14&p1=%3A&ah=1))
8 |
9 | ### [Resolutions from previous discussions](https://hackmd.io/tjFOwoqqTIid4jtfmVzkLg)
10 |
11 | ## Participants
12 | * Karen Coyle
13 | * Tom Baker
14 | * Phil Barker
15 | * John Huck
16 |
17 | ## Announcements
18 |
19 | * LD4P call for proposals - done
20 | * If accepted, should include more tech, including validation
21 | * dates are: July 12 to 23
22 |
23 | ## Agenda
24 | * OK [final draft](https://github.com/dcmi/dctap/blob/main/TAPprimer.md) of primer
25 | * Change title
26 | * add "keywords" for valueNodeType
27 | * fix broken table and CSV example
28 | * Where to document/test validation code?
29 | * New issues: label for next version?
30 | * Options for a manifest [#16](https://github.com/dcmi/dctap/issues/16)
31 | * Wikidata qualifiers in DCTAP? [#18](https://github.com/dcmi/dctap/issues/18)
32 | * Consider ordering of values [#14](https://github.com/dcmi/dctap/issues/14)
33 | * Winnowing of [DCAP issues](https://github.com/dcmi/dcap/issues)
34 | * xsd:anyURI (TBA)
35 |
36 | ## Minutes
37 |
38 | For draft:
39 | * Implement Tom's comments:
40 |
41 | - Profile Overview, first sentence: I suggest using "schema"
42 | instead of "scheme". In DC usage, "scheme" was always only
43 | ever used for "Encoding Schemes" - a usage that was picked
44 | up in "SKOS Concept Scheme".
45 |
46 | - Section "Properties": suggest changing
47 |
48 | http://xmlns.com/foaf/spec/#term_familyName
49 |
50 | to
51 |
52 | http://xmlns.com/foaf/0.1/familyName
53 |
54 | which is both best practice and in line with the
55 | prefix exammple in the section "Namespace Declarations".
56 |
57 | - valueDataType: The CSV example does not display, perhaps
58 | because the second row has one column too many.
59 |
60 | - valueNodeType: suggest changing
61 |
62 | It can be IRI, blank node or literal.
63 |
64 | to:
65 |
66 | Valid keywords are "IRI", "bnode", and "literal" (case-insensitive).
67 |
68 | * Change examples to have "bnode" and "literal" in lower case
69 |
70 | * Change title to DC Tabular Application Profiles (DC TAP)
71 | * Rollout requires a blog post - Karen will draft shortly
72 | * Plan rollout of document and blog post (and other announcements) for after April 14 meeting.
73 | * Karen: check vocabulary doc for needed changes
74 | * Add an introduction to the TAP document saying where to comment (github or email list)
75 | * Consider a new document, a "cookbook", for issues like:
76 | * ordering
77 | * multiple entries in a cell
78 | * open/closed
79 | * and other "implementation issues"
80 | * Karen: get back to Justin to see if our suggestions have helped him
81 |
82 | * Code:
83 | * Tom: will create a module that does basic checking of TAP. This will need to be documented (either in vocabulary document or some other document)
84 | * Karen: volunteers to create test data
85 |
86 |
87 |
--------------------------------------------------------------------------------
/meetings/2021/2021-04-14.dcap_zoom_call.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting April 14, 2021
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/tKE7fYVhS8GW11ISPPTnTg
6 |
7 | **Time:** 14:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20210414T14&p1=%3A&ah=1))
8 |
9 | ### [Resolutions from previous discussions](https://hackmd.io/tjFOwoqqTIid4jtfmVzkLg)
10 |
11 | ## Participants
12 | * Karen Coyle
13 | * Tom Baker
14 | * Phil Barker
15 | * Ben Riesenberg
16 | * Nishad Thalhath
17 | * John Huck
18 |
19 | ## Agenda
20 | * OK [final draft](https://github.com/dcmi/dctap/blob/kcoyle-patch-2/TAPprimer.md) of primer (see [minutes of previous meeting](https://hackmd.io/k7TsgsfCSSGEWm9wm3BgGQ))
21 | * Changed title
22 | * added "keywords" for valueNodeType
23 | * added text about commenting, other documents
24 | * Remaining questions
25 | * example with xsd:anyURI? https://github.com/dcmi/dctap/issues/20
26 | * nothing about multiple options in a cell (see https://github.com/dcmi/dctap/issues/12#issuecomment-795863555) Is this cookbook material?
27 | * OK [final draft](https://github.com/dcmi/dctap/blob/kcoyle-patch-2/TAPvocabulary.md) of vocabulary document
28 |
29 | ## Other topics
30 | * Where to document/test validation code?
31 | * New issues: label for next version?
32 | * Options for a manifest [#16](https://github.com/dcmi/dctap/issues/16)
33 |
34 | * Cookbook - github wiki as work area?
35 | * Wikidata qualifiers in DCTAP? [#18](https://github.com/dcmi/dctap/issues/18)
36 | * Consider ordering of values [#14](https://github.com/dcmi/dctap/issues/14)
37 | * Winnowing of [DCAP issues](https://github.com/dcmi/dcap/issues)
38 |
39 | Minutes:
40 |
41 | Tom: OK to not include multiple options text in the current draft. Could lead to less than useful discussion. However, use this to start cookbook. And we should ask people to let us know how they are using TAP so we can add things to the cookbook.
42 |
43 | Phil: Also, create a template for gathering info about use:
44 | - which elements from TAP did this use?
45 | - any elements they needed to add because not in TAP
46 | - what is the community or domain context?
47 | - what are the base standards they work with?
48 | - what did they want to do but could not?
49 |
50 | Ben: Vocab document seems to solidly define the TAP as RDF, because of propertyID which is an IRI, but the primer hedges that TAP is not necessarily RDF. (kc, later: is this a difference between TAP and what a profile defines?)
51 |
52 | kc: propID in vocab is defined as "compatible with an RDF vocabulary" - does this need to change?
53 |
54 | Tom: stay with this for now; people may want to just write in a term without a namespace.
55 |
56 | kc: change line to "identified vocabulary term"?
57 |
58 | ben: it will be interesting if we hear from folks who are not using RDF: what will they put for propertyID?
59 |
60 | CONCLUSION: leave it as is for now
61 |
62 |
--------------------------------------------------------------------------------
/meetings/2021/2021-05-12.dcap_zoom_call.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting May 12, 2021
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/9-2UlIRDQL6f0hdNasylPw
6 |
7 | **Time:** 14:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20210512T14&p1=%3A&ah=1))
8 |
9 |
10 |
11 | ## Participants
12 | * Karen Coyle
13 | * Tom Baker
14 | * John Huck
15 | * Nishad Thalhath
16 | * Phil Barker
17 |
18 | ## Agenda
19 |
20 | * Draft announced? [blog post](https://www.dublincore.org/blog/2021/draft_tap_specification/)
21 | * [Test records](https://github.com/dcmi/dctap/tree/main/tests)
22 | * [Pull request](https://github.com/dcmi/dctap/pull/27) to fix XSD link
23 | * [Ordered values](https://github.com/dcmi/dctap/issues/14)
24 | * Action KC: Suggest to Justin: either create his own `ordered` column (if needed for processing) and/or use the note field (for cataloger instructions)
25 | * We can put this in the cookbook until we either decide to add it to TAP or we create an extension method
26 | * [Manifest](https://github.com/dcmi/dctap/issues/16)
27 | * Nishad's [example](https://github.com/dcmi/dctap/issues/16#issuecomment-835835598)
28 | * Karen's [example](https://github.com/dcmi/dctap/issues/16#issuecomment-835838994)
29 | * Phil's JSON [example](https://github.com/dcmi/dctap/issues/16#issuecomment-836837419)
30 |
31 | * Action: Nishad to create YAML example
32 | * John to see if OAI-ORE would be useful
33 |
34 | [Cookbook draft](https://hackmd.io/V3LGdBdxTrOid57M2wJUlw)
35 |
36 |
--------------------------------------------------------------------------------
/meetings/2021/2021-06-09.dcap_zoom_call.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting June 9, 2021
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/Wnmud_CzQ9ifEzoaTcrtrg
6 |
7 | **Time:** 14:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20210609T14&p1=%3A&ah=1))
8 |
9 |
10 |
11 | ## Participants
12 | * Tom Baker
13 | * Nishad Thalnath
14 | * Karen Coyle
15 |
16 | ## Agenda
17 |
18 | ### Decide on output model for from CSV to ?? programs
19 |
20 | Some questions:
21 | * structured YES
22 | * start? NO
23 | * shape if only properties? YES
24 |
25 | see also [Issue 33](https://github.com/dcmi/dctap/issues/33)
26 |
27 | **NEED TO DEFINE AND DOCUMENT OUTPUT DATA MODELS FOR: JSON, YAML, XML (?)**
28 | ### e.g. table with shapes
29 |
30 | DCTAP
31 | Shape
32 | shapeID: :book
33 | start: True
34 | Statement
35 | propertyID: dct:creator
36 | shape_ref: person
37 | Shape
38 | shapeID: :person
39 | Statement
40 | propertyID: foaf:name
41 | or
42 | DCTAP
43 |
44 | shapeID: :book
45 | start: True
46 | propertyID: dct:creator
47 | shape_ref: person
48 | shapeID: :person
49 | propertyID: foaf:name
50 |
51 | **Decided: shape and statement levels are needed to contain the output elements; shape level is needed with tables that only have properties so that the data model is always the same**
52 |
53 | ### e.g. table with properties only
54 |
55 | DCTAP
56 | Shape
57 | shapeID: @default
58 | start: True
59 | Statement
60 | propertyID: dct:creator
61 | value_type: URI
62 | Statement
63 | propertyID: dct:date
64 | value_type: Date
65 | Statement
66 | propertyID: dct:extent
67 | value_type: Integer
68 |
69 | ### table with properties before shape
70 | 
71 |
72 | DCTAP instance
73 | Shape
74 | shapeID: :default
75 | start: True
76 | Statement Constraint
77 | propertyID: dct:title
78 | valueNodeType: literal
79 | Statement Constraint
80 | propertyID: dct:publisher
81 | valueNodeType: URI
82 | Shape
83 | shapeID: book
84 | Statement Constraint
85 | propertyID: dct:creator
86 | valueNodeType: BNODE
87 | Shape
88 | shapeID: author
89 | Statement Constraint
90 | propertyID: rdf:type
91 | valueNodeType: URI
92 |
93 | ### Consistency checking, i.e.:
94 | * check column headers? YES
95 | * pass through those not TAP? YES
96 | * give message for those not TAP? WARNING
(because this could be a typo)
97 | * check values in valueNodeType? NEED TO DECIDE
98 | * check valueConstraintTypes? NEED TO DECIDE
99 |
100 | ### Shape without ShapeID
101 |
102 | 
103 |
104 | DCTAP instance
105 | Shape
106 | shapeID: :default
107 | shapeLabel: Book
108 | start: True
109 | Statement Constraint
110 | propertyID: dct:title
111 | valueNodeType: literal
112 | valueDataType: xsd:string
113 | Statement Constraint
114 | propertyID: foaf:name
115 | valueNodeType: literal
116 | valueDataType: xsd:string
117 | **THIS SHOULD PROBABLY BE AN ERROR**
118 |
119 | ### Message outputs
120 |
121 | See [issue 32](https://github.com/dcmi/dctap/issues/32)
122 | * what should be returned from the program?
123 | * screen and/or file?
124 |
125 | ## Cover types of validation
126 |
127 | See issues [29](https://github.com/dcmi/dctap/issues/29) [30](https://github.com/dcmi/dctap/issues/30) [31](https://github.com/dcmi/dctap/issues/31) [32](https://github.com/dcmi/dctap/issues/32)
128 |
129 | * Close issue [28](https://github.com/dcmi/dctap/issues/28)?
130 |
--------------------------------------------------------------------------------
/meetings/2021/2021-06-23.dcap_zoom_call.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting June 23, 2021
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** [https://hackmd.io/Wnmud_CzQ9ifEzoaTcrtrg](https://hackmd.io/lQ-I0bKzQmCwl78xtgWfDw)
6 |
7 | **Time:** 14:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20210623T14&p1=%3A&ah=1))
8 |
9 |
10 |
11 | ## Participants
12 | *
13 |
14 | ## Agenda
15 |
16 | ### Decisions from last meeting
17 | * structured YES
18 | * start? NO
19 | * shape if only properties? YES
20 | * check column headers? YES
21 | * pass through those not TAP? YES
22 | * give message for those not TAP? WARNING
(because this could be a typo)
23 | * check values in valueNodeType? NEED TO DECIDE
24 | * check valueConstraintTypes? NEED TO DECIDE
25 |
26 | From github issues:
27 | * Let column headers be case insenstive [issue 29](https://github.com/dcmi/dctap/issues/29)
28 |
29 | ### Where "we" are with the program
30 | * https://dctap-python.readthedocs.io/en/latest/
31 | * output to file on command line
32 | *
33 |
34 | ## Other notes
35 | Phil: yes to case insensitive; only the initials need to be there
36 |
37 | kc: need to look again at value datatype, value constraint, to see if we are satisfied with the ones we have
38 |
39 | phil: this will be difficult; but there are lots of datatypes out there
40 |
41 | kc: yes, as long as folks using profile understand. ADD TO COOKBOOK
42 |
43 | nishad: it outputs json and yaml; either to screen or pipe to other program or send to file. And messages can go to screen or log
44 |
45 | kc: what do we need to do next?
46 |
47 | nishad: we need practical use cases and/or adoptions. we will have a library that other programmers can use.
48 |
49 | kc: srap may be a good use case
50 |
51 | phil: dctap for credentials organization agency. Wanted to make it fit with SHACL validation, so added columns and sheets
52 |
53 | kc: having separate definition of shapes does seem to be needed. How to connect shape sheet to property sheet
54 |
55 | Phil: (begins sharing) Shapes have a sheet with their own labels and comments, plus the severity for validation. In property sheet can have dropdown for shapes. ditto valueNodeTypes. Another shape is for metadata about the tap and the prefixes.
56 |
57 | kc: may use this example because the BIBFRAME folks are using SHACL
58 |
59 | kc: we still need to figure out how to do prefixes.
60 |
61 | nishad: this is in the program has defaults and can be configurable. We do need to figure out what the defaults will be if no local configuration is provided.
62 |
63 | kc: (shows config module) Need something more human friendly. What else do we need to configure - column headings have been mentioned. Tom wants short forms; maybe this should be in the configuration file
64 |
65 | Phil: APs - Nancy HobelHeinrich doing APs for RDA (research data). For training materials for research data.
66 |
67 | kc: Also in SRAP doing DataCite in TAP
68 |
69 | Phil: Feedback from draft?
70 |
71 | kc: No. Assume people don't have time to read - best to do conferences and webinars
72 |
73 | Nishad: use case: Need multi-lingual labels. Doing "propertyID, propertyID-jp". (With EN as default.) In YAML these are keys. COOKBOOK
74 |
75 | kc: in RDF you could use "@xx" and put them in a single cell.
76 |
77 | Nishad: that gets messy because labels can be long, can have spaces, etc. This way has been easier to parse. Also need multi-lingual notes.
78 |
79 | Nishad: how to align with other "profile" packages, e.g. Frictionless data specification
80 | frictionlessdata.io. Have a lot of tools, validation tools, etc. We have some datasets already published in this package. Uses some of the same terms as DC TAP.
81 |
82 | ISSUES: config and prefixes
83 | -- multi-lingual content (labels and notes)
84 |
85 | Can close issues #28, #30, #32, #33
86 |
87 |
88 |
89 |
--------------------------------------------------------------------------------
/meetings/2021/2021-07-07.dcap_zoom_meeting.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting July 7, 2021
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/YV8H_NDWRmmnMMrDt6m7Tg
6 |
7 | **Time:** 14:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20210707T14&p1=%3A&ah=1))
8 |
9 |
10 |
11 | ## Participants
12 | *
13 |
14 | ## Agenda
15 |
16 | * Upcoming: LD4 presentation July 23
17 | * Mention: SRAP, DataCite and DCAT work to transform to DCTAP
18 | * DCTAP-Python - demonstration, discussion
19 | * Currently following the [primer](https://github.com/dcmi/dctap/blob/main/TAPprimer.md), and documented in [readthedocs](https://dctap-python.readthedocs.io/en/latest/)
20 | * [Basic TAP validation, issue 29](https://github.com/dcmi/dctap/issues/29)
21 | * Question of allowing through unknown headers but with a warning.
22 | * Allowing case insensitive etc is done
23 | * [TAP shape/output structure, issue 30](https://github.com/dcmi/dctap/issues/29)
24 | * Brings up topic of open/closed and whether a new table is needed for more definition of shapes. See [Phil's comments](https://github.com/dcmi/dctap/issues/30#issuecomment-858827013)
25 | * [TAP contents](https://github.com/dcmi/dctap/issues/31)
26 | * question on [values with white spaces](https://dctap-python.readthedocs.io/en/latest/elements/valueConstraintType/Picklist/index.html) in picklist
27 | * [pattern checks for valid regex](https://dctap-python.readthedocs.io/en/latest/elements/valueConstraintType/Pattern/index.html) - do we need to accommodate other kinds of patterns? Or skip regex check?
28 | * [IRIstem](https://dctap-python.readthedocs.io/en/latest/elements/valueConstraintType/IRIStem/index.html) Now can be more than one with spaces
29 | * [Language tag](https://dctap-python.readthedocs.io/en/latest/elements/valueConstraintType/LanguageTag/index.html) Multiples allowed; use of @?
30 | * ShapeID gets [warning if not IRI-type](https://dctap-python.readthedocs.io/en/latest/elements/shapeID/index.html)
31 |
32 | # Tests
33 |
34 | |element|tests|
35 | |----|----|
36 | |TAP overall|propertyID required; exits|
37 | |TAP headers|case insensitive; white space, _ - removed; only TAP headers output|
38 | |propertyID|must be IRI or compact IRI|
39 | |propertyLabel|assumed to be a single string|
40 | |mandatory|"1/0 or true/false"|
41 | |repeatable|"1/0 or true/false"|
42 | |valueNodeType|"IRI or URI, Bnode, Literal; or any SHACL combined value; others get warning"|
43 | |valueDataType|warning if not IRI; warning if IRI or BNODE given literal value|
44 | |valueConstraint|treated as literal unless NodeType IRI/Bnode|
45 | |valueConstraintType – picklist|splits on whitespace; question on values with internal whitespace|
46 | |valueconstraintType – pattern|checks for valid regex|
47 | |valueConstraintType – IRIstem|checks to see if seems like an IRI; allows more than one|
48 | |valueConstraintType – LanguageTag|allows multiples using spaces; doesn't include “@”|
49 | |valueShape|any warnings?|
50 | |shapeID|if none, default is provided|
51 | |shapeLabel|assumed to be a single string|
52 | |note|assumed to be a single string|
53 |
54 | * [Outputs, issue 32](https://github.com/dcmi/dctap/issues/32) Can be closed?
55 |
--------------------------------------------------------------------------------
/meetings/2021/2021-11-11.dcap_zoom_call.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, November 11, 2021
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/FPEx1_qMS9GyMlv2PupWFw
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20211111T15&p1=%3A&ah=1))
8 |
9 | **Present**
10 |
11 | *
12 |
13 | ## Agenda
14 |
15 | ### Announcements
16 |
17 | * [DCAT-US](https://github.com/dcmi/dctap/tree/main/examples/dcat-ap-us) added to examples
18 | * Progress on software?
19 |
20 | ### Vocabulary file updated
21 | * [diff](https://github.com/dcmi/dctap/commit/c3741184596460361346b4e55921a5905ce2e5ef#diff-c32dea882670a753b4b7b8bda6db370af4ce7d60972230d7bfaf2f417ce720f6)
22 | * Close ISSUE [Modify mandatory/repeatable in Vocab document](https://github.com/dcmi/dctap/issues/52)
23 |
24 | ### Work on primer
25 | * [Draft](https://hackmd.io/DErWH403RaWiBippMFosaw) in progress
26 |
27 | phil: converting TAP to shacl
28 |
29 | tom: I thought of shacl as a profile
30 |
31 | phil: there may be a use case for converting SHACL into TAP. I've been working on an EU DCAT AP
32 |
33 | phil: did a [blog post](https://blogs.pjjk.net/phil/shacl-when-two-wrongs-make-a-right/) regarding shacl, where things do not get checked nor do they fail? it doesn't give you the feedback.
34 |
35 | kc: how will TAP be expressed in SHACL? Where does open/closed fit in?
36 |
37 | phil: yes, that changes things, but more study needed. SHACL doesn't test everything you might want, like do the terms in your graph actually exist in the namespace you are referencing?
38 |
39 | tom: would require content negotiation online
40 |
41 | phil: should be trivial in specific cases
42 |
43 | kc: hmmm, would open refine be usedful? because it works with tabular data.
44 |
45 | ACTION: kc find someone to ask about open refine and TAP
46 |
47 | john: there are extensions to open refine that may be useful. can query databases, etc. Maybe a TAP extension?
48 |
49 | phil: what about exporting directly from google sheets?
50 |
51 | kc: add to implementation document
52 |
53 | **Changes to vocab file**
54 |
55 | OK, and kc will close github issue
56 |
57 | **Primer updates**
58 |
59 | kc: reorganizing to keep statement constraints together, followed by shape information
60 |
61 | **Implementation document**
62 |
63 | Can we agree on an outline?
64 |
65 | tom: software environments where it has been implemented. point to examples? or is this mainly a guide?
66 |
67 | kc: last time we decided to separate tap from implementation, e.g. manifest. The 3 needs that Phil stated.
68 |
69 | phil: scope of implementing - how to create AP, how to create table (e.g. templates in excel, sheets, etc.), how tap can be processed. Latter is very open field. But there are so many things that could be done, so it would be speculative to go much further
70 |
71 | john: also implies the whole metadata implementation that is too broad
72 |
73 | tom: john samuel gave call-out to TAP as a potential helper for wikidata data. limit document to things that are working well, point to their documentation
74 |
75 | kc: could point to known implementations from readme, and should point to dctap-python. Implementation doc can say: you can add columns
76 |
77 | tom: things that you can configure. not clear where to address open/closed. do shacl and shex have same defaults. in shex you can say "closed" so open is the default
78 |
79 | phil: in shacl may work differently
80 |
81 | tom: we don't need a default for tap - but we should discuss it
82 |
83 | phil: adding in some things for shacl, like a column for level of violation. and a sheet with information about the node classes, because that's how shacl works.
84 |
85 | tom: could be a section about shacl, and a section about shex. not related to any particular program.
86 |
87 | kc: people want to add classes and ranges. means you don't have to go back to original vocabulary.
88 |
89 | tom: not good practice to change ranges
90 |
91 | kc: schema.org sometimes gives you more than one.
92 |
93 | phil: APs need to be valid against base vocabulary. should be ok to narrow range. but AP range statement is for validation, not for redefinition
94 |
95 | tom: we could suggest that things that we see as violating the AP concept be included only as annotations. and warn against use.
96 |
97 | ACTION: make sure documents make a clear statement about APs not violating the base vocabularies that they use
98 |
99 | ACTION: Tom and Karen - review 2008 AP document, and perhaps add dc tap to examples
100 |
101 | phil: at what point do we move this to DCMI pages?
102 |
103 | ACTION: primer isn't linked. kc: make issue in DC web github. Phil will send kc page for group, and kc will suggest updates
104 |
105 | (Nishad is now web manager. There is a ticketing tech.)
106 |
107 | tom: DC TAP should be more visible on site
108 |
109 | kc: should at least be in list of specifications.
110 |
--------------------------------------------------------------------------------
/meetings/2021/2021-11-25.dcap_zoom_call.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, November 25, 2021
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/UiwmJpyMRb2UuuHnhexLOA
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20211125T15&p1=%3A&ah=1))
8 |
9 | **Present**
10 |
11 | * Tom
12 | * Phil
13 | * Karen
14 |
15 | ## Agenda
16 |
17 | ### Announcements
18 |
19 | * [DCAT-AP 2.1.0](https://github.com/SEMICeu/DCAT-AP/blob/2.1.0-draft/releases/2.1.0/dcat-ap_2.1.0.pdf) in progress. Karen will update the example.
20 | * edited [readme](https://github.com/dcmi/dctap/blob/main/README.md) to include implementations
21 | * ? anything else?
22 |
23 | ### Work on Primer
24 |
25 | * on [Hackmd](https://hackmd.io/DErWH403RaWiBippMFosaw) for easier commenting
26 | * [through cardinality](https://github.com/kcoyle/dcap/commit/9fec61a9e3763991f907741cfdf91b7381def268#diff-28cc19f2013c7b9e915c4c8a3ac5b2c668e8a02e5c6852dd027cfbed2e1be01b)
27 | * [value constraints and shape](https://github.com/kcoyle/dcap/commit/6b997c563baf279a62cbb35928c9a4ef81b841d6#diff-28cc19f2013c7b9e915c4c8a3ac5b2c668e8a02e5c6852dd027cfbed2e1be01b)
28 | * Does this satisfy [issue #35](https://github.com/dcmi/dctap/issues/35)?
29 |
30 | ### Beginning implementation document
31 | * https://github.com/dcmi/dctap/blob/main/ImplementingTAP.md
32 | * copied over namespace info from primer
33 | * did a section on validation - here, or the cookbook?
34 |
35 | ## Minutes
36 |
37 | * added implementation section to readme
38 |
39 | **Primer updates**
40 |
41 | kc: changes in kcoyle github repo and coordinated with hackmd version. comments can be done on hackmd.
42 |
43 | kc: document reorganized to keep statements together. appendices may be deleted later
44 |
45 | kc: many editorial changes. asking Tom: does this satisfy issue #35.
46 |
47 | tom: header Statements header - statements are in data; in tap they are constraints
48 |
49 | ACTION: "Constraints on statements, their properties, and values"
50 |
51 | ACTION: each
52 |
53 | cardinality: = statement cardinality?
54 |
55 | kc: edits on property values and shapes.
56 |
57 | tom: literal datatypes - type is not itself literal.
58 |
59 | phil: datatypes for literals
60 |
61 | (checking XML document and RDF document)
62 |
63 | ACTION: use statement from RDF document with minor edits; include links to RDF document AND XML datatype document. Add the RDF-defined values (langstring ...?)
64 |
65 | Note that we have a value constraint type of langstring which is the list of valid languages. Is this confusing?
66 |
67 | Value Constraint: a pattern for the value
68 |
69 | phil: confusion between pattern and value constraint type pattern
70 |
71 | tom: a string is also a pattern
72 |
73 | phil: should value constraint type be more specific and a "regex". From programming point of view you want to know exactly what the pattern is
74 |
75 | kc: many flavors of regex. and folks may use non-regex patterns. can call them 'programmable expressions' or 'actionable expressions'
76 |
77 | phil: folks can define a more specific type for particular types of regex
78 |
79 | ACTION: phil to create github issue for this - change pattern to regex?
80 |
81 | ACTION: FIX regex example which markdown munges
82 |
83 | Shapes: kc: how do shapes in tap connect to shapes in instance data? in shacl much use of classes.
84 |
85 | phil: target of node shape is all nodes of specific class, or named node
86 |
87 | kc: want a version of phil's multi-sheet tap in examples. Good example for people
88 |
89 | phil: could be an implmentation of TAP.
90 |
91 | ACTION: Phil will set up google sheet that people can view
92 |
93 | tom: implementation document should have examples with shex and shacl
94 |
95 | phil: a standard can only standardize so much; the rest is left to implementation. Example of implementation guide:
96 | https://www.imsglobal.org/metadata/mdv1p3/imsmd_bestv1p3.html
97 |
--------------------------------------------------------------------------------
/meetings/2021/2021-12-09.dcap_zoom_call.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, December 9, 2021
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/KeH_S-zVSAigAF97qdQOzw
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20211125T15&p1=%3A&ah=1))
8 |
9 | **Present**
10 |
11 | * Tom Baker
12 | * Karen Coyle
13 | * Phil Barker
14 | * John Huck
15 |
16 | ## Agenda
17 |
18 | ### Announcements
19 |
20 | * Work continues on RDA/LRMI metadata TAP - Phil announces that there are multiple efforts in LRMI group relating to application profiles. They may form a subgroup for LRMI AP thoughts
21 | * No word yet from DataCite, also looking at TAP
22 | * Some outline sections added to [ImplementingTAP](https://github.com/dcmi/dctap/blob/main/ImplementingTAP.md)
23 | ACTION: Karen will add a header for Phil's multiple sheet solution
24 |
25 | ### Work on Primer
26 |
27 | * on [Hackmd](https://hackmd.io/DErWH403RaWiBippMFosaw) for easier commenting
28 | * [updates from last meeting, through line 158](https://github.com/kcoyle/dcap/commit/dc58cc199db3113c4906b846f19238aaa435c2c9#)
29 | * [value constraints and shape](https://github.com/kcoyle/dcap/commit/6b997c563baf279a62cbb35928c9a4ef81b841d6#diff-28cc19f2013c7b9e915c4c8a3ac5b2c668e8a02e5c6852dd027cfbed2e1be01b)
30 |
31 | ## Minutes
32 |
33 | In talking about Shapes, Tom questions use of "entity" - a metadata thing or a thing in the world. Shape is a category, not an instance. Use "type"?
34 |
35 | John: what are we talking about in this sentence?
36 |
37 | kc: what would we call the boxes in the diagram? Use resource instead of entity?
38 |
39 | phil: no one word is going to be clear. We may need to rephrase the sentence.
40 |
41 | tom: (reads from his dctap-python) "statements about a distinct entity in the world is a description". Name things in instance data differently from their names in the TAP.
42 |
43 | phil: list of metadata properties in an AP.
44 |
45 | john: entities plural used later - type or class of entity; or an entity in a model
46 |
47 | tom: statements expected to be found in a description.
48 |
49 | kc: not happy with 'description'. don't find it used in that way.
50 |
51 | tom: we need a name for the group of statements in instance data.
52 |
53 | kc: we need a name for something in the metadata (instance) that describes something in the world.
54 |
55 | john: making a model - model is an abstraction
56 |
57 | phil: a single list of metadata properties may provide a model for describing a type of entity - entities are real world, entity types are models
58 |
59 | property constraints - single list of properties and their constraints. single list of constraints on statements, their properties and values
60 |
61 | kc: do we have constraints on statements, or do we have properties and their constraints, and that makes up a statement?
62 |
63 | tom: statement is in the metadata - statement constraint is in TAP
64 |
65 | john: I like 'properties and their constraints'. property constraints puts 'constraint' as the main noun, where as the property is the key element
66 |
67 | tom: properties are in metadata, not tap
68 |
69 | kc: do we need to say how the shape in the tap connects to the shape in the metadata.
70 |
71 | phil: shapes are in the profile. but how do you connect from the shape to the metadata?
72 |
73 | tom: could be rdf class declaration.
74 |
75 | phil: I don't like using the identifier of the shape to match the instance data. in shacl a shape can match a type, it can match objects or subjects of a property, or a shape can match a single instance.
76 |
77 | kc: do an example with shapeID as a URI?
78 |
79 | tom: No, that conflates the shapeID.
80 |
81 | DECISION: leave as an open issue; put examples in the implementation guide.
82 | ACTION: Tom will write a sentence about shex
83 |
84 | john: not so much xml but databases where data is stored.
85 |
86 | ACTION: create test instance data
87 |
88 | ## Next meeting
89 |
90 | Dec. 23 is too close to xmas eve. Next is January 6.
91 |
92 | ## Agenda items we didn't get to
93 | * [Issue #60](https://github.com/dcmi/dctap/issues/60) Rename "pattern"
94 | * [Issue #61](https://github.com/dcmi/dctap/issues/61) valueDataTypes for Shapes (Comment made on Hackmd version)
95 |
--------------------------------------------------------------------------------
/meetings/2022/2022-01-06.dcap_zoom_meeting.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, January 6, 2022
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/5rLR1ypiT7OCxhJYSEw8NA
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20211125T15&p1=%3A&ah=1))
8 |
9 | **Present**
10 |
11 | *
12 |
13 | ## Agenda
14 |
15 | ### Announcements
16 |
17 | Tom: ShEx call - calling "discriminators" e.g. type arc. Discriminators can be more than one property. Type arc may be missing or wrong. Don't try to validate things that are not what they say they are. Used to decide what shape is to be validated.
18 | phil: sometimes the object of a property is the discriminator
19 | kc: same property can have different values, e.g. IRI or literal. If those are on two different lines then they are different things. If you define the target as something with this property and this value type, how do you know if there is a property with a different value type? If you start with the rules, then you don't see what didn't match.
20 | phil: shacl will not indicate what doesn't match; shex does. SHACL alone will not do all validation
21 | kc: TAP is "asperational" but doesn't actually do validation.
22 |
23 | Phil: overview of samples of instance data for [simple book](https://github.com/dcmi/dctap/tree/main/examples/simple-book)
24 | Interesting case: if TAP says only one title, and you provide titles in different languages, that is invalid. open_book_extra.ttl has extra property.
25 | phil: real instance data is much more complex, and more is needed to be able to test everything.
26 |
27 |
28 | ### Work on Primer
29 |
30 | * on [Hackmd](https://hackmd.io/DErWH403RaWiBippMFosaw) for easier commenting
31 | * [updates from last meeting](https://github.com/kcoyle/dcap/commit/1139539362d917ecd29ba728013172142c955672#diff-28cc19f2013c7b9e915c4c8a3ac5b2c668e8a02e5c6852dd027cfbed2e1be01b)
32 | * Decide: "pattern" or "regex"? https://github.com/dcmi/dctap/issues/60 See also "use HTML pattern" https://github.com/dcmi/dctap/issues/49
33 |
34 | Only small changes.
35 | * valueShape means no valueDataType, but can have valueNodeType
36 |
37 | * renaming pattern to regular expression?
38 | * Nishad: I like pattern because regex is implementation specific. XML calls it "pattern" but says to use regex. HTML5 pattern comes from javascript specification
39 | * phil: need to use the regex that downstream programs will use
40 | * nishad: we should recommend to use HTML pattern, but people can override that
41 | * kc: do we need a way to specific the flavor of regex in the TAP?
42 | * nishad: general recommendation should be XML because we are using XML data types
43 | * phil: default is assumed to be XML regex; else use configuration file
44 | * kc: config file or TAP itself?
45 | * phil: if you are using more specific expressions, you are doing something quite sophisticated. Most regex are compatible with a few exceptions.
46 | * nishad: you can do a picklist in regex
47 | * kc: regex could do everything
48 | * nishad: how do we say how to write a picklist?
49 | * kc: we punted on that. I moved the section on multiple values from the primer to the cookbook.
50 | * nishad: can we adopt a standard regex for this?
51 | * phil: regex \= easy
52 | * nishad: could be a pipe (that would be regex)
53 | * phil: we say: multiple values in any cell is an "OR". So, do we really need to say that it is a picklist? You only need the picklist type when the value would be ambiguous.
54 | * kc: your (Phil) multiple table example uses line feeds between values
55 | * phil: I found that different separators make sense in different columns. Config file may need to indicate on a per-column basis.
56 | * kc: I thought about doing "one of[x, y, z]" to show that it is a choice
57 | * tom: encourage people to extend DC TAP, so they could have a more specific solution
58 | * kc: we can show various methods in the cookbook
59 | * tom: it may not be a good idea to assume the TAP must be interoperable; that is very constraining. I prefer that we provide something simple but not set high expectations for interoperability
60 | * kc: put statement to this effect at top of cookbook - that this is a very simple model; you should feel free to make modifications for your needs. Just know that modified TAP may not be usable by others without some explanation.
61 | * phil: I do want to be able to exchange TAPs, so we do need defaults that will be easy to implement
62 | * kc: what can we say here about the picklist? the example shows commas. "one or more values from which to choose with some known separator that is defined in a configuration file if needed."
63 | * tom: need a sensible default
64 | * phil: i still wonder what picklist means - if more than one value, picklist is the default. Can be more than one IRIstem, or languageTag. Both of these can get multiples.
65 | * kc: will make a github issue
66 |
--------------------------------------------------------------------------------
/meetings/2022/2022-03-10.dcap_zoom_meeting.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, March 10, 2022
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/uZe-siwkTOmKGmiaJy2X3w
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20220310T15&p1=%3A&ah=1))
8 |
9 | ## Participants
10 |
11 | * Tom Baker
12 | * Phil Barker
13 | * Karen Coyle
14 | * John Huck
15 | * Nishad
16 |
17 | ## Announcements
18 | * Karen made suggested editorial changes to [Primer](/DErWH403RaWiBippMFosaw)
19 | * key/value -> key-value
20 | * added "TAP example" above examples (Phil had suggested below but I couldn't find a neat way to do that with markdown)
21 |
22 | ## Agenda
23 |
24 | Let's see if we can finish up the framework, and look at a suggested modification to the definition of AP for the primer. The parts of the frame work to look at are Karen's rewrite of the "vocabularies and models" section, and then the final section on application profiles.
25 |
26 | * Framework: https://hackmd.io/7RT1MstvS7yumgVwbtFm2A
27 | * Github issue: https://github.com/dcmi/dctap/issues/35
28 | * [The Singapore Framework](https://www.dublincore.org/specifications/dublin-core/singapore-framework/)
29 | * Definition issue: https://github.com/dcmi/dctap/issues/66
30 |
31 | ## Minutes
32 |
33 | Karen's "simplified" vocabs and models section.
34 |
35 | Tom: need to remove "standard", and "schema"
36 |
37 | Karen: domain model isn't a vocabulary. Like FRBR + BIBFRAME + BIBFRAME profiles
38 |
39 | Tom: a profile needs to profile something. It profiles the metadata. May draw on a model. Providing rules is the profile. Vocabs and domain models are ok, but not necessarily standards. The raw materials.
40 |
41 | Phil: An application profile will be based on existing vocabularies and models.
42 |
43 | Phil & Tom: a profile may supply the model - doesn't necessarily come first
44 |
45 | kc: e.g. DCAT, have a model and use other vocabularies. But there is a model they are using the vocabularies within
46 |
47 | Tom: The profile can define the model, e.g. if your profile has shapes. Model doesn't have to be written down before the profile.
48 |
49 | kc: Agree. The question is how can you create a profile if you don't have (at least in your head) and idea of the metadata model you are creating.
50 |
51 | kc: we don't want all metadata using existing vocabs to be a profile. What wouldn't be an AP?
52 |
53 | Phil: DC terms
54 |
55 | tom: we can say DCAT is build on DC terms in the same way that we can say that a house is built out of bricks. It's not build just out of bricks, but that's still true.
56 |
57 | John: a defacto profile, could exist, e.g. in XML where you can mix and match in the metadata without a schema. Why is Karen concerned?
58 |
59 | kc: Too big to bite off. We need a well-defined scope for TAP or our problem is too big.
60 |
61 | Tom: boils down to the term "uses". Domain model and vocabs DEFINE, but an AP USES. Not always a clear distinction. DCAT already uses, so it's ambiguous
62 |
63 | (Heery and Patel defintion here)
64 |
65 | phil: "combined together" is where you get the model. Their "schema" means model
66 |
67 | kc: I think their "schema" is our TAP
68 |
69 | tom: add schema to How to confuse everybody. problem is unqualified use of "schema"
70 |
71 | "... profile draws on vocabularies"
72 |
73 | tom: vocabs and data models are the raw materials of metadata (added to text)
74 |
75 | tom: difference between property and class vocab and a concept schema. concept schemes are value vocabularies.
76 |
77 | phil: concepts aren't terms (as we've defined it) descriptive terms that are properties and concept schemes (that are values?). Not good to go straight into concept schemes -
78 |
79 | kc: call it list instead of scheme? or move it? do lists belong in AP?
80 |
81 | tom: part of raw materials.
82 |
83 | phil: one type = properties, classes; another = lists, enumerations. (Phil made changes)
84 |
85 | " ... which can be used to describe the characteristics of an entity" - connects with first section. Metadata standards can have usage rules. Thinking of this as a style guide, do we need this? Do we need to state that there is documentation? There is no confusion over how documentation is spoken of. Move to first para - usage rules part of schema.
86 |
87 | kc: a profile expresses a domain model
88 |
89 | kc: let's see what we need when we define AP - in terms of documentation.
90 |
91 | kc: what do we want to say about RDF? First part of each section is general, then RDF comes later.
92 |
93 | (Tom gives suggestions, Phil types) (Then Phil comes up with language for predicates/properties)
94 |
95 | John: I've done a paper on the uses of the term "ontology" - We all want to read it!
96 |
97 | John: Daylight savings. ACTION: kc to send email with options (DONE)
98 |
99 |
--------------------------------------------------------------------------------
/meetings/2022/2022-03-17.dcap_zoom_meeting.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, March 17, 2022
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/-VlkCU_DTxaDLVgynnA1mg
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20220310T15&p1=%3A&ah=1))
8 |
9 | ## Participants
10 |
11 | * Phil Barker
12 | * Tom Baker
13 | * Karen Coyle
14 | * John Huck
15 | * Nishad
16 |
17 | ## Meeting time
18 | 1. Stay at the same local time by moving to 14:00 UTC
19 | 2. Continue at 15:00 UTC, meaning local time will be +1 hour
20 |
21 | DECISION: continue with 15:00 UTC
22 |
23 | ## Agenda
24 |
25 | Today it's the "Application Profiles" section of the framework.
26 |
27 | * Framework: https://hackmd.io/7RT1MstvS7yumgVwbtFm2A
28 | * Github issue: https://github.com/dcmi/dctap/issues/35
29 | * [The Singapore Framework](https://www.dublincore.org/specifications/dublin-core/singapore-framework/)
30 | * Definition issue: https://github.com/dcmi/dctap/issues/66
31 |
32 | ## Minutes
33 |
34 | John: we should talk about this at the DCMI meeting
35 |
36 | kc: and webinars! SWIB, etc.
37 |
38 | kc: Define application profile
39 |
40 | phil: I was less clear about this part
41 |
42 | kc: we haven't actually defined the application profile - maybe something before "additional to".
43 |
44 | tom: APs have a history in DCMI. Add something here?
45 |
46 | kc: acknowledge that on our github repo.
47 |
48 | tom: will this be part of spec or separate?
49 |
50 | phil: best as a style guide; perhaps informing the terms declaration (tap vocab document)
51 |
52 | kc: that doc is very concise; perhaps adding this would be a bit more expansive.
53 |
54 | tom: "how models and vocabularies are used in a metadata instance..."
55 |
56 | kc: statement constraints -> constraints on metadata statements found in the instance data. (Doesn't include shapes.)
57 |
58 | kc: next paragraph - talks about "parts" but ...
59 |
60 | phil: what to call the columns?
61 |
62 | tom: we've called them elements - another one of those overused terms
63 |
64 | john: are constraints general? or is a row a constraint? Also, say "set of constraints on metadata statements"
65 |
66 | tom: rows are rules for statements... rows define constraints on statements, and columns have individual rules for the statements.
67 |
68 | john: what would we call one row? statement constraint?
69 |
70 | tom: that's the main thing but also includes name for the shape. if we say rows are constraints on statements, that goes too far
71 |
72 | john: but what does a row represent?
73 |
74 | tom: that's why I say "holds" because it can hold statement and shape
75 |
76 | john: are constraints the same as rules?
77 |
78 | phil: a row holds a statement constraint and a statement constraint contains rules
79 |
80 | tom: and also elements? what's difference between constraint, rule, and element?
81 |
82 | tom: I prefer constraint to rules
83 |
84 | kc: I prefer rule to constraint
85 |
86 | phil: constraint is all of the rules taken together
87 |
88 | tom: I see a rule as having expressivity and a constraint is an element of a rule
89 |
90 | john: each cell contains a rule. the columns don't have the rules. some columns have labels, etc.
91 |
92 | kc: columns have types of rules
93 |
94 | phil: an element is part of a statement constraint, and the element is what's in the cell. also not every cell with have a rule in it. sometimes more than one cell is needed to define a rule (value constraint and type).
95 |
96 | "columns for the elements of the rules"
97 |
98 | john: individual elements are in separate columns; switch word order
99 |
100 | kc: we are tripping up on the difference between defining THE tap and defining A tap. We need to decide which this is.
101 |
102 | phil: that would be the next section. THE tap is what the vocab file defines.
103 |
104 | kc: the first section defines the tap. Do we need to distinguish between CSV values and comma-separated individual cell entries.
105 |
106 | tom: is "entry" a cell value?
107 |
108 | phil: a cell can have more than one entry
109 |
110 | kc: can we not address this here? we haven't mentioned saving as CSV. That is in the primer. Also, we have defined "value" in the metadata area, and it would mean something different here.
111 |
112 | kc: next is to define shape.
113 |
114 | "is a set of statement constraints"
115 |
116 | tom: relates to a common entity; is a set of constraints about a common ... entity?
117 |
118 | tom&phil: need something like "node" in the metadata section.
119 |
--------------------------------------------------------------------------------
/meetings/2022/2022-04-17.dcap_zoom_mg.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, April 14, 2022
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/oCYqvJjlSWijHKaCKCXujw
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20220414T15&p1=%3A&ah=1))
8 |
9 | ## Participants
10 | * Karen
11 | * John
12 | * Nishad
13 | * Tom
14 |
15 | ## Announcements
16 | [New issue](https://github.com/dcmi/dctap/issues/68) from Bert relating to tooling, and vocabulary vs. AP. (Also relates to DCAT-AP)
17 |
18 | ## Agenda
19 |
20 | The main agenda item is to decide whether "shape" is a thing in the metadata, in the profile, or in both. See issue #67, but also TimBL's explanation of [shapes, forms, and footprints](https://www.w3.org/DesignIssues/Footprints.html) which are audience-centric, and Ruben's [blog post](https://ruben.verborgh.org/blog/2019/06/17/shaping-linked-data-apps/). Some questions:
21 | * Are these "shapes" the same as "views"?
22 | * Are they in the metadata? or only in the "viewer"?
23 | * Do we need to address the audience for our framework sections?
24 |
25 |
26 | **Links**
27 | * What's a shape? https://github.com/dcmi/dctap/issues/67
28 | * Framework: https://hackmd.io/7RT1MstvS7yumgVwbtFm2A
29 | * Github issue: https://github.com/dcmi/dctap/issues/35
30 | * [The Singapore Framework](https://www.dublincore.org/specifications/dublin-core/singapore-framework/)
31 | * Definition issue: https://github.com/dcmi/dctap/issues/66
32 |
33 | ## Minutes
34 |
35 | kc: new issue by Bert - difference between AP and vocabulary. We have said that the AP is about usage and vocabulary is about defining terms. This works for RDF; may be less obvious in XML or JSON.
36 |
37 | kc: main work today is to talk about shapes. We have said that shapes are in the profile, but not clear what we want to say about what is in the data or the model. I have suggested that we say that metadata has structures; these are different in different models. The metadata has units that gather statements.
38 |
39 | john: in xml the structure is always there; RDF has no records, just an open graph. AP comes out of vocabulary side; shapes from the data side.
40 |
41 | kc: no one disagrees with talking about structure in model
42 |
43 | john: do we need to use the term structure?
44 |
45 | kc: can't think of another term that covers XML, RDF, and database storage
46 |
47 | tom: separate semantics from structure?
48 |
49 | kc: problem is the flow we have here which goes from real world -> metadata model -> vocabulary. Shouldn't vocabulary precede model? We would need that to be able to talk about semantics.
50 |
51 | nishad: we have semantics before we encode metadata in our concepts. and profile contains semantics. (seems to be semantics throughout)
52 |
53 | kc: we haven't included semantics at all - maybe best not to. But maybe switch vocabulary and metadata sections.
54 |
55 | john: vocabulary is specific to RDF. Metadata model is more general.
56 |
57 | kc: called "data elements" in other formats. "Attributes" in O-O. Also, best not to expand this more.
58 |
59 | Tom: "vocab data models and raw materials of metadata" -
60 |
61 | john: that may be too RDF-specific because of vocabs. We havent discussed vocabs and what we mean by them. Brings up difference between vocab and AP.
62 |
63 | kc: at end, after vocabulary say "also called data elements and terms".
64 |
65 | kc: now: AP section. statement constraints vs constraints in the columns. Edit: shapes can be a view over the metadata, not necessarily the same structures are in metadata. e.g. sparql or db query
66 |
67 | john: main concept of profile is that it is the profile of a standard.
68 |
69 | kc: tim b-l document is done in terms of audience. tap can be for multiple audiences. 1) can define metadata to be created 2) can define md to be extracted 3) can be used to validate md. Include "purposes" in the primer. Primer says: creation and reuse. Maybe include more examples in Primer.
70 |
71 | John: Be clear that "node" is very RDF.
72 |
73 | kc: A shape is a node, but may not be a node in the metadata.
74 |
75 | john: "for a node in the metadata"
76 |
--------------------------------------------------------------------------------
/meetings/2022/2022-04-28.dcap_zoom_meeting.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, April 28, 2022
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/TpOWp93CSwS4rsjWYozMhQ
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20220428T15&p1=%3A&ah=1))
8 |
9 | ## Participants
10 | * John, Karen, Phil, Nishad, Tom
11 |
12 | ## Announcements
13 | * John & Karen to do a DC TAP tutorial at DC 2022 (will need help!)
14 | * Karen in CET for the month of May
15 |
16 | ## Agenda
17 |
18 | * [DC Tabular Application Profiles (DC TAP) - Primer](/DErWH403RaWiBippMFosaw) questions
19 | * [Re-written intro](/H8rRdV4LSNeMAcdvCEJskA) (see [comparison](https://docs.google.com/document/d/1NuVaaB6dfVE9b_n1jFKpa6pT_XZlAXaCTJaDhCF3INY/edit))
20 | * Should we move cardinality to the end of the statement section?
21 | * "case insensitive" - maybe make this just a suggestion
22 |
23 | ## Minutes
24 |
25 | Framework: Phil volunteers to finish up. Publish it as a note. Phil will send framework to editor of a profile he is working on.
26 |
27 | Profile introduction:
28 | tom: have we used "function"?
29 | phil: usage v use - how instance data could be used
30 | tom: usage is style
31 | - leave usage, can change later
32 |
33 | kc: dropped property-value pairs - not mentioned in framework. Then: text v machine-actionable profiles.
34 |
35 | Add a section on extension. Phil: say extending is easy, just add a column.
36 |
37 | ACTION: Phil will add short section to primer.
38 |
--------------------------------------------------------------------------------
/meetings/2022/2022-06-09.dcap_zoom_meeting.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, June 9, 2022
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/dOVU8r98TpaiEYTr_ozTQA
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20220609T15&p1=%3A&ah=1))
8 |
9 | ## Participants
10 |
11 |
12 | ## Announcements
13 |
14 |
15 |
16 | ## Agenda
17 |
18 | * [DC Tabular Application Profiles (DC TAP) - Primer](/DErWH403RaWiBippMFosaw)
19 | * Still only edited to line 177
20 | * One heads up about picklist
21 | * [Cookbook](https://hackmd.io/V3LGdBdxTrOid57M2wJUlw) has:
22 | * min/max cardinality
23 | * min/max values
24 | * Namespace declaration
25 | * Multiple values in a cell
26 | * Defining order of properties
27 | * Defining order of values
28 |
29 | ## Minutes
30 |
31 | Dealing with mandatory properties that can have empty values: Nishad: can use a regular expression rather than xsd:string that says: string or empty is valid. But can also ask for "none" or "null" instead of empty string.
32 |
33 | phil: multiples in cell are alternatives. You can say that it's string or null. (May not be a null in xsd).
34 |
35 | nishad: also use type for casting, like numerical IDs cast to string.
36 |
37 | kc: address in TAP?
38 |
39 | nishad: hard to include what you really need "in the wild" in TAP. Ended up going back to data package after all
40 |
41 | kc: Primer --
42 | last time we talked about multiple values, and we said we'd deal with those in the cookbook -- but we still have picklist. I'll say: is a list, separate as you wish, more info in cookbook. Somewhere in document we will say: if you think you need to use multiple values in a cell, look at the cookbook for examples.
43 |
44 | phil: the way I remember it we weren't removing all references to multiple values. I discussed putting som eof the more complex ones in the cookbook, like separators. keep: processed as logical "or".
45 |
46 | kc: if we want to make a general statement then it needs to not be just in the valueConstraint area but in an area that is more general.
47 |
48 | tom: it's fine to generalize and say "logical or" but cookbook should go through each element to say what it might mean.
49 |
50 | kc: could be examples
51 |
52 | phil: leave in 'logical or' and say that booleans can only have one value.
53 |
54 | tom: in the abstract you can say there are multiple values in a cell but an implementation would need to know which ones are taking multiples, and what the separator is. That's outside the scope of the base specification. Maybe say that communicating this downstream is application specific. My program uses a config file, others may do it differently.
55 |
56 | kc: we say: need to convey to downstream users
57 |
58 | **Cookbook**
59 | kc: Lists issues that have been moved from github to cookbook. Others should edit with different ideas. Issues will be closed when covered.
60 |
61 | **DCAP github issues**
62 |
63 | (Group closes issues, moves some, and leaves the ones that were case studies and requirements for documentation purposes.)
64 |
65 | To do: shapes on a separate row. Not clear what that means - because only shape label would be unchanged.
66 |
67 | To do: what to say about relationship of AP to base vocab - cookbook. Must conform to specification it is profiling. Say this in primer? Yes. Sentence or two in primer.
68 |
69 | #62 - can you create a TAP for classes? Phil: this is out of scope. Close as out of scope.
70 |
71 | "profile"" vs "profiles" - Karen will make sure this is used in the documents.
72 |
73 | Phil: "DCMI specification for Tabular Application Profiles"
74 |
75 | john: it's a "community specification"
76 |
77 | kc: still need to decide if we will create a formal vocabulary
78 |
79 | tom: space: dc tap, or without dctap?
80 |
81 | #57 Quick statements as an alternative syntax - if someone does an example we will add that
82 |
83 | All remaining issues can be looked at for possible cookbook items.
84 |
85 | kc: Copy Framework to repo.
86 |
87 | Phil: how do we "socialize" this work with the rest of dcmi?
88 |
89 |
--------------------------------------------------------------------------------
/meetings/2022/2022-07-07.dcap_zoom_meeting.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, July 7, 2022
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** [https://hackmd.io/mKcvYrWQTfiWNk6K1VYWHw](https://hackmd.io/v7P5LqBRTl6_qMUdnbHn5w)
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20220623T15&p1=%3A&ah=1))
8 |
9 | ## Participants
10 |
11 | * John, Nishad, Tom, Karen, Phil
12 |
13 | ## Agenda
14 |
15 | * Cookbook updates ([diff]((https://github.com/dcmi/dctap/commit/97953ca02fe9cb65bca16fbe61d7fe9c5fbd690c))). Or comment on [hackmd draft](/V3LGdBdxTrOid57M2wJUlw)
16 | * Phil updated min/max length and min/max value in the cookbook
17 | * Karen updated "Specific cardinality"
18 | * Karen created [paragraph](https://lists.dublincore.org/pipermail/application-profiles-ig/2022-July/000675.html)) to include:
19 | * multiple values in a cell are alternatives
20 | * each row is interpreted independently
21 | * all rules on a row must be validated
22 | * Continue with [cookbook issues](https://github.com/dcmi/dctap/issues?q=is%3Aissue+is%3Aopen+label%3Acookbook)
23 |
24 | ## Minutes
25 |
26 | Tom: need a template for the cookbook. Need something that can be published on DC web site.
27 |
28 | kc: copy and paste from excel to markdown works. but it's not just the tables
29 |
30 | phil: readthedocs is markdown. nkdocs also
31 |
32 | **Cookbook changes**
33 |
34 | changes have been pushed to github
35 |
36 | Phil did min/max values and lengths.
37 |
38 | kc: cookbook needs a section on how to read TAP. (phil gives example: contact details are mandatory, but can be either address or email. CE Organization TAP)
39 |
40 | tom: what do these two rows mean? both need to match?
41 |
42 | phil: yes
43 |
44 | tom: what if you have two and they are "or"?
45 |
46 | phil: two values in a cell
47 |
48 | kc: there are limits on logic (if-then-else). Some might be possible with shapes, but not all. TAP is a SIMPLE profile (maybe we should have gotten "S" into the name)
49 |
50 | kc: ACTION - make that example less confusing. Just do "max" at the beginning. Then show a min/max.
51 |
52 | kc: "specific cardinality" - cannot be a value constraint because cardinality is not a value. This uses columns
53 |
54 | phil: am doing this in taps that convert to shacl, so this works
55 |
56 | kc: added this into Primer in "using a TAP":
57 | * multiple values in a cell are alternatives
58 | * each row is interpreted independently
59 | * all rules on a row must be validated
60 |
61 | kc: ACTION try "using language indicators in strings" - langstring for RDF, other for XML or JSON? the latter would be "add a column" #44
62 |
63 | tom: not rules, just examples
64 |
65 | kc: #45 Lists of things not in RDF (e.g. do not have URLs) (Phil: "I need this: I have a text field that is US state or CA province") This is a kind of modularity.
66 |
67 | phil: can be a separate sheet with a range reference. not a general solution.
68 |
69 | kc: how to link from TAP to some other file
70 |
71 | tom: cookbook could have section on how to use multiple sheets in TAP environment
72 |
73 | kc: #70 is about modularizing. Easy if you have the same columns, but not withg different tables with different columns
74 |
75 | john: not clear why this example doesn't meet our idea of picklist. (list has values like )
76 |
77 | phil: two problems: one) is the size of the list in the TAP, which is hard to manage all in one cell two) this data may be used in more than one shape. So need to store the list elsewhere and use it
78 |
79 | phil: need something like $include in JSON schema.
80 |
81 | kc: would that work in the value constraint? including that would be part of the processing of the TAP.
82 |
83 | phil: it's the human side that is a concern. But does the $include become part of the TAP or is it a processing convention for those who use it
84 |
85 | tom: the latter
86 |
87 | phil: ACTION add example in cookbook
88 |
89 | Phil: in README on dctap github - move "Primary documents" to top. Add style guide
90 |
91 | KC: DONE
92 |
--------------------------------------------------------------------------------
/meetings/2022/2022-07-21.dcap_zoom_meeting.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, July 21, 2022
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/cIBL3fheSuKDBRDQ6irlKw
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20220721T15&p1=%3A&ah=1))
8 |
9 | ## Participants
10 |
11 | * Regrets from John
12 | * Karen, Nishad, Tom, Phil
13 |
14 | ## Agenda
15 |
16 | * Cookbook updates pushed to github - [diff](https://github.com/dcmi/dctap/commit/97953ca02fe9cb65bca16fbe61d7fe9c5fbd690c).
17 | * Includes Phil's min/max sections + Karen added one simple example
18 | * [Cookbook draft](https://hackmd.io/V3LGdBdxTrOid57M2wJUlw)
19 | * Discuss ideas for templating/formatting cookbook
20 | * Continue with [cookbook issues](https://github.com/dcmi/dctap/issues?q=is%3Aissue+is%3Aopen+label%3Acookbook)
21 |
22 | ## Minutes
23 |
24 | * Statement template with valueShape #75 - should "shape" be a valueType?
25 | * Decided that NO
26 | * If using valueNodeType, can be IRI BNODE
27 | * If not using valueNodeType, valueType is left blank
28 | * Add two examples to Cookbook
29 |
30 | ACTION: KC try to understand what is the equivalent to shape in JSON Schema. Based on [this](https://www.mongodb.com/basics/json-schema-examples) it appears that JSON Schema `object` is close to the shape idea.
31 |
32 | ? Add a valueConstraintType in documentation for min/max length. ??
33 | tom: those are xsd literal facets
34 | kc: prefix with xsd: ?
35 | all: not needed, just say in documentation that it comes from xsd
36 |
37 | Here's what's in XSD:
38 | **string** has the following [·constraining facets·](https://www.w3.org/TR/xmlschema-2/#dt-constraining-facet):
39 |
40 | - [length](https://www.w3.org/TR/xmlschema-2/#rf-length)
41 | - [minLength](https://www.w3.org/TR/xmlschema-2/#rf-minLength)
42 | - [maxLength](https://www.w3.org/TR/xmlschema-2/#rf-maxLength)
43 | - [pattern](https://www.w3.org/TR/xmlschema-2/#rf-pattern)
44 | - [enumeration](https://www.w3.org/TR/xmlschema-2/#rf-enumeration)
45 | - [whiteSpace](https://www.w3.org/TR/xmlschema-2/#rf-whiteSpace)
46 |
47 | **decimal** has the following [·constraining facets·](https://www.w3.org/TR/xmlschema-2/#dt-constraining-facet):
48 |
49 | - [totalDigits](https://www.w3.org/TR/xmlschema-2/#rf-totalDigits)
50 | - [fractionDigits](https://www.w3.org/TR/xmlschema-2/#rf-fractionDigits)
51 | - [pattern](https://www.w3.org/TR/xmlschema-2/#rf-pattern)
52 | - [whiteSpace](https://www.w3.org/TR/xmlschema-2/#rf-whiteSpace)
53 | - [enumeration](https://www.w3.org/TR/xmlschema-2/#rf-enumeration)
54 | - [maxInclusive](https://www.w3.org/TR/xmlschema-2/#rf-maxInclusive)
55 | - [maxExclusive](https://www.w3.org/TR/xmlschema-2/#rf-maxExclusive)
56 | - [minInclusive](https://www.w3.org/TR/xmlschema-2/#rf-minInclusive)
57 | - [minExclusive](https://www.w3.org/TR/xmlschema-2/#rf-minExclusive)
58 |
59 |
60 | * Then follows a long discussion about formatting of cookbook, including these:
61 |
62 | 00:31:28 Nishad Thalhath: https://tabatkins.github.io/bikeshed/
63 | 00:33:40 Nishad Thalhath: https://www.princexml.com
64 | 00:34:04 Nishad Thalhath: https://docbook.org
65 | 00:36:18 Nishad Thalhath: https://respec.org
66 | 00:40:33 Nishad Thalhath: https://commonmark.org
67 | 00:49:54 Nishad Thalhath: https://www.tablesgenerator.com/markdown_tables
68 |
69 | Also readthedocs and sphinx and mkdocs.
70 |
71 |
72 |
73 |
74 |
75 |
76 |
77 |
--------------------------------------------------------------------------------
/meetings/2022/2022-08-18.dcap_zoom_meeting.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, August 18, 2022
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** [https://hackmd.io/kyBNOA2ZT1OeI0yLio1CHA](https://hackmd.io/a9GF0Cu2SB6Zx61rFIxgMg)
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20220818T15&p1=%3A&ah=1))
8 |
9 | ## Participants
10 |
11 | * Regrets: Phil
12 |
13 | ## Agenda
14 |
15 | Decisions and actions from last meeting, for review:
16 | * Add min-maxLength and min-maxInclusive to Primer
17 | * [Diff](https://github.com/dcmi/dctap/commit/a87e4f40805792b162da01343fa26e26cd116d9a)
18 | * Do not define relationship between TAP and metadata (TAP may define structure but not necessarily)
19 | * Add [sections to Cookbook](https://hackmd.io/V3LGdBdxTrOid57M2wJUlw?view#DCTAP-and-data-validation) for validation, e.g. SHACL, ShEx (#77 #78, assigned to Phil and Tom)
20 | * Issues closed: #19, #66, #67, #76
21 |
22 |
23 |
--------------------------------------------------------------------------------
/meetings/2022/2022-09-01.dcap_zoom_meeting.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, September 1, 2022
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/Ue4Y5Nx8Qcu0YYnRZFdgCQ
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=202200901T15&p1=%3A&ah=1))
8 |
9 | ## Participants
10 |
11 | * John, Karen, Tom, Phil, Nishad
12 |
13 | ## Agenda
14 |
15 | **From last meeting**
16 | * edits to Primer for `langString` and some copy edits
17 | * [Diff](https://github.com/dcmi/dctap/commit/18cb0b02513540d0ff9be877c4bf849e8365b4fc)
18 | * Some questions about [shapes section](https://hackmd.io/DErWH403RaWiBippMFosaw?view#Shapes) in Primer
19 |
20 | **[Cookbook](https://hackmd.io/V3LGdBdxTrOid57M2wJUlw)**
21 | Right now is organized into sections "added values" and "added columns" which probably is not the user view. What criteria should we use for ordering? An "I want to ..."? Simple to complex? What should we say are methods? (e.g. multiple values in a cell; repeating properties for added constraints; etc.)
22 |
23 | Minutes:
24 |
25 | Tom: We should publish "talking about metadata" document. But where?
26 |
27 | kc: could create section on profiles in general with prior work and TAP.
28 |
29 | ACTION on All: Look at site and think about where to put our documents.
30 |
31 | Once published, needs a short announcement explaining WHY
32 |
33 | PRIMER - Shapes section
34 |
35 | ACTION: kc - fix case problems in shape examples (and check examples in github)
36 |
37 | ACTION: kc - move repetition of shapes in rows to appendix.
38 |
39 | phil: combine value shape and shapeID in section and text?
40 |
41 | John: Examples: first show as strings, then "when you need to say more" introduces shapes
42 |
43 | Shapes and properties:
44 | Phil: "The string in the valueShape column is a shapeID that indicates the shape defintion used to constrain the value of property."
45 |
46 | or: "The string in the valueShape column is the same as a shapeID of a shape definition in the TAP. (The shape definition used to constrain the value of property.?)
47 |
48 | provides a shape definition as the value of the property
49 |
50 | john: defines a shape block in the TAP
51 |
52 | Cookbook:
53 |
54 | Needs to be re-organized to reflect user view, not extending elements and extending table. Karen and Phil need to talk.
55 |
56 | Notes: 01:05:09 John Huck: I like Phil's solution (connects the value of the property to a shape)
57 | 01:05:31 Phil Barker: The string in the valueShape column is used to constrain the value of property by reference to a shape defintion.
58 | 01:06:02 Phil Barker: The string in the valueShape column is used to constrain the value of property by reference to a shape defintion using a shapeID
59 | 01:08:41 Karen Coyle: https://github.com/dcmi/dctap/blob/main/talking_about_metadata.md
60 | 01:10:17 Phil Barker: The string in the valueShape column is a shapeID that indicates the shape defintion used to constrain the value of property.
61 | 01:10:39 Karen Coyle: thanks phil. copied it
62 | 01:17:47 John Huck: https://www.dublincore.org/conferences/2022/programme/
63 |
--------------------------------------------------------------------------------
/meetings/2022/2022-09-29.dcap_zoom_meeting.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, September 29, 2022
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/q0YCEvM6S3C63hssBhNLMA
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=202200929T15&p1=%3A&ah=1))
8 |
9 | ## Participants
10 |
11 | * John, Karen, Tom, Phil, Nishad
12 |
13 | ## Agenda
14 |
15 | * (Final?) edits to [Primer](https://github.com/dcmi/dctap/blob/main/TAPprimer.md)
16 | * added Phil's diagram
17 | * added short section on extending
18 | * [Tutorial plans](https://drive.google.com/drive/u/0/folders/1khRVc-ZCQppiSRHsurdjDN7wRXp_rZt4)
19 | * sent to mailing lists
20 | * tweeted
21 | * Note: tutorial is FREE so let people know
22 | * [Page and registration](https://www.dublincore.org/conferences/2022/sessions/tutorial-dctap/)
23 | * Next steps?
24 |
25 |
26 |
27 |
--------------------------------------------------------------------------------
/meetings/2022/2022-10-27.dcap_zoom_meeting.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, October 27, 2022
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/VQQIRK43SeG-PPUCdPy6MA
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=202200929T15&p1=%3A&ah=1))
8 |
9 | ## Participants
10 |
11 | * Tom, Nishad, Phil, Karen
12 |
13 | ## Agenda
14 |
15 | **Vocabulary document**
16 |
17 | * Review vocabulary document
18 | * [Copy for comments](https://hackmd.io/Q6nvIs_FSLmLmeOhso66_Q)
19 | * ("statement constraint" to "statement template" already done)
20 |
21 | **Manifest**
22 | * have we decided not to define a manifest?
23 | * https://github.com/dcmi/dctap/issues?q=is%3Aissue+is%3Aopen+label%3Amanifest
24 |
25 | ### Minutes
26 |
27 | (some lost at beginning because not recorded)
28 |
29 | **Vocabulary document**
30 |
31 | * [copy on hackmd ](https://hackmd.io/Q6nvIs_FSLmLmeOhso66_Q)
32 |
33 | Change "property" to "element" - not declaring them as RDF properties at this time
34 |
35 | Delete datatype column because confusing at "meta" level
36 |
37 | Some things aren't elements - e.g. shape and statement template. Remove those, but explain elsewhere
38 |
39 | Nishad: "component" tap has 3 - shape, statement and statement elements
40 |
41 | Needs a diagram!
42 |
43 | Issues with cardinality related to TAP+shape+statementTemplate vs TAP+statementTemplate
44 |
45 | Diagram - UML or ? UML can show elements and cardinality
46 |
47 | Drop datatype column; cover that in text, and don't be strict about datatypes
48 |
49 | For propertyType - not necessarily an IRI. Say literal or IRI but recommend IRI
50 |
51 | Nishad: propertyID sounds like an IRI
52 |
53 | Phil: how it's worded: "unique within the context of this profile" is good. PropertyID needs to be globally unique term
54 |
55 | Nishad: "property" is external, but propertyID is local as soon as you add it to the profile
56 |
57 | Phil: that's 2 different things; if using dcterms need that IRI in profile otherwise you don't know what you are using
58 |
59 | Nishad: confusing that both are ID and one is local and one is not
60 |
61 | tom: one use of dctap is for rapid prototyping, and it should be acceptable to use a placeholder for the propertyID
62 |
63 | nishad: is shapeID a class?
64 |
65 | kc: not always; and classes are not always structures in RDF
66 |
67 | phil: put something here about propertyLabel and RDF label?
68 |
69 | kc: make a section in the cookbook. already listed as issue #72
70 |
71 | phil: label used here is local; not necessarily same as label in RDF vocabulary.
72 |
73 | tom: this should go in the primer (kc: added to nov 24 meeting)
74 |
75 | Add to primer: "can differ from label in underlying vocabulary"
76 |
77 | phil: valueNodeType: could this be used for XML structures? they have "leaf nodes" but not clear if other elements are thought of as nodes. "node type of value node" then say that when using RDF the available types are: etc.
78 |
79 | phil: change "built-in" to minimum set; "minimum set of values for RDF" in all areas
80 |
81 | tom: what is it built-in to? data model?
82 |
83 | nishad: documents will go under dublincore/specifications/dctap
84 |
--------------------------------------------------------------------------------
/meetings/2022/2022-11-24.dcap_zoom_meeting.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, November 24, 2022
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/wi_ZmqFMRsCLrXA25b3JlQ
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20221124T15&p1=%3A&ah=1))
8 |
9 | ## Participants
10 |
11 | * John, Phil, Tom, Karen
12 |
13 | ## Agenda
14 |
15 | From Oct. 27 meeting: add to primer:
16 |
17 | Add to primer: "can differ from label in underlying vocabulary"
18 | KC to add - DONE
19 |
20 | Note definition of valueNodeType in Primer
21 | KC copy over from vocabulary - DONE
22 |
23 | "Documents in this Project" - add to each document. Point to github?
24 | https://hackmd.io/zxDR8FazSCKx6X_V6DK28w?both
25 | KC - add to each
26 |
27 | **Vocabulary document**
28 |
29 | * [Document draft](https://hackmd.io/bwmOpD-7TH2EcQVg4r9QYQ?view) Draft has been re-ordered
30 | * [Diagrams by Kc and Phil](https://docs.google.com/presentation/d/1KSv_807T8OtceZIJBHnbpy_0vwUMJg4KoYxplmAl5z0/edit#slide=id.g199b2684445_0_0)
31 | * [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)
32 | * Is title ok? We talk about "elements" in the document
33 |
34 | Discussion of vocab document:
35 |
36 | kc made two categories: concepts v elements
37 |
38 | The table:
39 | * kc reduced to structure, cardinality, component
40 |
41 | Cardinality:
42 | ok
43 |
44 | Diagrams:
45 | * default shape along with actual shape. Is that too confusing?
46 | * Phil - there can only be one default shape
47 | * kc - default shape is not named in the TAP
48 | * Phil - should diagrams say "default shape" and "named shape"
49 | * John - do we have examples with both a default and a named shape?
50 | * 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
51 | * 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
52 | * tom - can of worms. model doesn't have way to decide what in metadata gets evaluated. like shex shapemap. Also, shex has 'start shape'.
53 | * 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
54 | * kc - want to discourage the combination of default and named shapes?
55 | * john - what does dctap program do?
56 | * phil - creates shape named 'default'
57 | * tom - like the bnode of shapes
58 | * phil - if applies to all instances in the TAP can be efficient - all sdo:name are langstring.
59 | * tom - this is very implementation specific
60 | * DECISION **discourage this** just show the shapes and the default in separate diagrams
61 |
62 | Cardinality of default
63 | * john - in terms of cardinality, does this mean there is always a shape?
64 | * kc - no shapeID or shapeLabel in the TAP; assigning default shape happens outside of DCTAP in implementation
65 | * e.g. oai-pmh dublin core
66 |
67 | Cardinality of shapes
68 | * table did have
69 | * john: should be zero or one in table because you may not have a shapeID because you do not have a shape
70 | * phil: if no shape id you still have a default shape, but it has no shapeID
71 | * kc: default shape is what happens in python program; it is not in the TAP
72 |
73 | ACTION: Change component in table to element
74 |
75 | phil: reverse the order of the columns, so element comes before cardinality and it is more clear that cardinality applies to element
76 |
77 | tom: or have two tables; shape and statement template. word 'component' could disappear
78 |
79 | 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.
80 |
81 | kc: do we want a uml diagram with all of the elements?
82 |
83 | tom: doesn't show how shapes link. Could do in a diagram.
84 |
85 | 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
86 |
87 | phil: say what the components are - DONE
88 |
89 | phil: delete word 'components' in structure column; change structure column to 'components'. Move structures to last column, with value on every row. - DONE (PHIL)
90 |
91 |
92 |
--------------------------------------------------------------------------------
/meetings/2023/2023-01-05.dcap_zoom_meeting.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, January 5, 2023
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/A710t0tlSrmGOprjdTfx5Q
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20221208T15&p1=%3A&ah=1))
8 |
9 | ## Participants
10 |
11 | * Tom, Nishad, Karen, Phil
12 |
13 | ## Agenda
14 |
15 | Note: list of project documents added to each document, e.g. https://github.com/dcmi/dctap/blob/main/TAPelements.md. They link to the .html versions.
16 |
17 | * Draft page for DC site
18 | * Hackmd https://hackmd.io/qpBNn0dbR_ypypgLHX4BYw
19 | * HTML at github.io https://dcmi.github.io/dctap/apPage.html
20 |
21 | (Note: edits were made during meeting.)
22 |
23 | Tom: add a banner to Guidelines and Singapore framework to DCTAP. These are related, not new versions
24 |
25 | * Thoughts on publicity
26 |
--------------------------------------------------------------------------------
/meetings/2023/2023-01-19.dcap_zoom_meeting.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, January 19, 2023
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/ZUODBdU1RJiE34qRCfRNOA
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20230119T15&p1=%3A&ah=1))
8 |
9 | ## Participants
10 |
11 | * john huck
12 | * phil barker
13 | * tom baker
14 | * nishad thalnath
15 | * karen coyle
16 |
17 | ## Agenda
18 |
19 | * Report out from SEMIC meeting
20 | * Tom reports: UML diagram is source of truth; UML to be start of workflow, which limits the diagraming. That is a kind of a profile of UML. Phil: statements are about SHACL shapes. Problem is in the different meanings of "class". Have to abide by underlying vocabulary definitions. "Light-weight ontology" for them is OWL lite. But also "can't cherry pick".
21 | * john: DDI cross-domain specification has UML as 'truth'
22 | * phil: problem with UML is it is closely aligned with object-oriented programming. DCTAP could be the single source of truth. esp. because doesn't use symbols
23 | * Review [bits](https://hackmd.io/8mgSE3UfTwCMoJ49Yl9IVw) for web site
24 | * Nishad: drop-down not needed; it will be under /specifications
25 | * group is application profiles, product is DCTAP
26 | * two short documents were completed during meeting
27 | *
28 | * Longer [web site page](https://hackmd.io/qpBNn0dbR_ypypgLHX4BYw)
29 | * Tom: put name of document first in bullet points
30 | * nishad: add a tsv starter file
31 |
32 | ACTION: remove dctap.ttl since we aren't doing a vocabulary (kc to put in her own repo)
33 |
34 | Phil: extended TAP template - will move to tap to shacl.
35 |
--------------------------------------------------------------------------------
/meetings/2023/2023-02-02.dcap_zoom_meeting.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, February 2, 2023
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/GndT4gM2R2Kt6WOlBUmDpw
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20230202T15&p1=%3A&ah=1))
8 |
9 | ## Participants
10 |
11 | * Karen, Tom, Phil, John
12 |
13 | ## Agenda
14 |
15 | * Changes made to [web site page](https://hackmd.io/qpBNn0dbR_ypypgLHX4BYw). Should be ready to go. Links in documents need to be changed to web site links (now are .io) Cookbook should remain .io, however
16 | * [Announcement and blog post](https://hackmd.io/xStNjvZESJOYTwu6-CoshA) - in progress
17 |
18 | ## Minutes
19 |
20 | 3 documents are ready to go onto web site. Have links that need to be changed to web site versions. KC will describe this in an email to Nishad at webmanager@dcmi.org.
21 |
22 | phil: are these drafts for comment?
23 | all: No, okay for them to be community specifications. (Change made to Primer during meeting)
24 |
25 | tom: 'about this document' - links to where to comment if there are any. We've made this available for a while.
26 |
27 | tom: put about this document first, then follow with table of contents. Call it 'about this specification'. Add brief description from 'about' page. Also, use better set of links to other documents (from 'about' page).
28 |
29 | Future work:
30 | * Cookbook, and extending TAP
31 | * phil: we have AND and OR but not NOT
32 | * add min/max cardinality prominently in Cookbook
33 | * programs - Tom: working on the shex converter. Will attend shex meeting in 10 days
34 | * from dctap to shex can be a way to learn shex because you see the shex syntax as the output. shex could become the 'source of truth' rather than dctap, but dctap starts as that
35 | * phil: projects that are generating shacl.
36 | * Could we engage with the SEMIC folks to use dctap instead of UML? Feedback is that using UML leads people down object-oriented road, and that isn't necessarily what people really intend.
37 | * Also working with IEEE on learning data, and will show them a dctap
38 | * may be working on a schema management tool, and it may be based on a TAP, along with other functions.
39 | * John, thinking about XML and Datacite. (kc: may need to be a separate document because could be long: moving from XML to TAP). John mentions the MODS standard. For some, use case for XML is stronger than use case for RDF.
40 | * Also, some ideas about geo data
41 |
42 | Next meeting: Tom can report back on Basel meeting.
43 |
--------------------------------------------------------------------------------
/meetings/2023/2023-03-02.dcap_zoom_meeting.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, 2 March, 2023
2 |
3 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
4 |
5 | **HackMD link:** https://hackmd.io/Wp5oY_X3Qn6Wvng63rImwg
6 |
7 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20230302T15&p1=%3A&ah=1))
8 |
9 | ## Participants
10 |
11 | * Karen, Phil, Tom, Nishad
12 |
13 | ## Agenda
14 |
15 | * News piece for DC website [here](https://hackmd.io/xStNjvZESJOYTwu6-CoshA)
16 |
17 | Dublin Core Metadata Initiative announces a stable version of DCTAP, a table-based model for the expression of application profiles. With only twelve elements, this model provides an extensible core that can be used to define, constrain, and explain the expected metadata usage.
18 |
19 | Specifications for DCTAP are available on the DC web site.[link] Community members are encouraged to share their experience with DCTAP through the Application Profiles Working Group email[link], or the DCTAP github repository[link].)
20 | kc: send to webmanager
21 | * Content ideas for blog post? https://blogs.pjjk.net/phil/
22 | * to be worked on
23 | * SRAP DCTAP and new [issue #90](https://github.com/dcmi/dctap/issues/90) - IRI stems for propertyID
24 | * it may be that this can only be done in user documentation
25 | * may related to open/closed, which we haven't resolved
26 | * there could be an additional column, but that would mean that in that case propertyID is not required
27 | * may also relate to the definition of namespaces; could say that included namespaces relate to open/closed; only terms in the namespaces are allowed; could namespace mean: use anything from example.com
28 | * tom: not clear how you would validate this
29 | * phil: like schema.org with http and https; make sure that every property can be foundk
30 | * basically decide that this is a form of guidance; but guidance is not machine-processable
31 | * maybe this is a profile of the profile
32 | * Have a look at Schemasheets [https://linkml.io/schemasheets/](https://linkml.io/schemasheets/)
33 | * sounds good, but no one fully understands it
34 | * Anyone going to SWIB23? SWIB23 15th Semantic Web in Libraries Conference, Berlin, 11-13 Sept. [http://swib.org/swib23/](http://swib.org/swib23/)
35 | * phil: maybe do a session on APs for learning resources
36 | * profiles vs application profiles - everyone starts with very general ideas
37 | * tom: would be too bad if dctap couldn't be used for rapid prototyping
38 | * Back to cookbook
39 |
40 | ###### tags: `dctap meetings`
41 |
--------------------------------------------------------------------------------
/meetings/2023/2023-03-16.dcap_zoom_meeting.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, 16 March, 2023
2 |
3 | ###### tags: `dctap meetings`
4 |
5 | **Zoom link:** https://us02web.zoom.us/j/85164307523?pwd=QTMybkFlSTJoUHA3cHp0NkZkU1ZZdz09
6 |
7 | **HackMD link:** https://hackmd.io/vXcsJpbFRXCiZeKCrz0OcA
8 |
9 | **Time:** 15:00 UTC ([check time](https://www.timeanddate.com/worldclock/fixedtime.html?msg=DC+TAP&iso=20230316T15&p1=%3A&ah=1))
10 |
11 | ## Participants
12 |
13 | * Tom, Phil, Karen, Nishad
14 |
15 |
16 | ## Announcements
17 | * news item sent to webmanager for posting (March 13)
18 |
19 | ## Agenda
20 |
21 |
22 | * Tab-delimited vs CSV - python program needs a command-line switch?
23 | * *Answer: Tom will look at how best to do this in python program; there may be a sniffer function; might work in config file.*
24 | * Display question [issue #91](https://github.com/dcmi/dctap/issues/91)
25 | * *Yes, separate lines for shapeID and shapeLabel is ok. Add some examples to cookbook; also one with shapeID on every row*
26 | * *Change close/start in readthedocs to ID and label, because close/start are not in primer*
27 | * *Tom: open/closed is problematic, shouldn't be in base model. Closed is difficult in SHACL*
28 | * *KC: include closed in cookbook? Hard to define - could be on shape, statement or even property*
29 | * *Tom: do this in sections on shex and shacl.*
30 | * SRAP DCTAP and new [issue #90](https://github.com/dcmi/dctap/issues/90) - IRI stems for propertyID
31 | * *Do we want to allow propertyID stem in DCTAP? Currently would fail on URI check in python*
32 | * *Tom: should be part of user guidelines. Not everything can translate directly to validation.*
33 | * *Phil: this is a different level of validation; can imagine a way to say: these are the vocabularies we recognize. But then you get into the question of open/closed. Also, how would you constrain them?*
34 | * *Say that this is part of user guidance. All of DCTAP can go into shex or shacl. But not all of shex or shacl can be expressed in DCTAP.*
35 |
36 | *Phil: shacl has property shapes that are modular in nature - treated the same in each instance. Also comes up in shex and yaml. Would eliminate repetition in the dctap.*
37 | *Tom: could this be done in an analysis of the table? Phil: that sounds complicated.*
38 | *phil: maybe a free-floating property statement but not in a shapeID.*
39 | *kc: python program assumes everything in a shape*
40 | *phil: I can process the default shape as being free-floaters. Possibly default DCTAP shape would be interpreted as a set of property shapes in shacl.*
41 |
42 | Time for next meeting: keep same UTC time?
43 |
--------------------------------------------------------------------------------
/meetings/2023/2023-09-28.dcap_zoom_meeting.md:
--------------------------------------------------------------------------------
1 | # DC TAP meeting Thursday, September 28, 2023
2 |
3 |
4 | **Zoom link:** [https://us02web.zoom.us/j/87806474887?pwd=MjRYVWV4MkVhOEZOTFE3MmxoN0pyUT09
5 |
6 | Hackmd link: https://hackmd.io/Xnswaj_uQgOevsDbIkckzw
7 |
8 | ## Participants
9 | * Phil, Nishad, Karen
10 |
11 | ## Agenda
12 |
13 |
14 | * Phil's time to talk about OCX and possible connection to AP group
15 | * Notes: Learning Tapestry open source K12
16 | * k12ocx.github.io
17 | * vocabulary uses schema.org, LRMI, OER
18 | * need to place their application profile core with a standards body
19 | * Questions: how can changes be made?
20 | * Is the core stable?
21 | * Elements and templates sections added to [primer](https://github.com/dcmi/dctap/blob/main/TAPprimer.md)
22 | * Is primer ready to be updated on DC site?
23 | * KC: send note to list with 2-week deadline
24 | * Examples compatible with github.io [see](https://github.com/dcmi/dctap/tree/main/examples)
25 | * Do a few more? How many? Which?
26 | * Ayy! Many examples on DCAP/prototypes. Those need to be gone through. Copy over any that can be DCTAP examples (after modifications). Delete others so that DCAP directory is not redundant with DCTAP
27 | * What next? Any possibility to get further on programs? Also see: Also see: https://huggingface.co/spaces/dcmi/dctap2shex/
28 | * Shex and shacl transforms are alpha (or maybe beta) and can be offered to coders to fork.
29 | * Tom's dctap-python might be ready for huggingface, but is definitely ready to be used by others.
30 | * These can be advertised on coder-adjacent lists, with a request to return any improvements
31 |
--------------------------------------------------------------------------------
/patterns.md:
--------------------------------------------------------------------------------
1 | # Patterns for Application Profiles and Constraints
2 |
3 | There are three main components of the application profile: entities, properties, and values. There are five primary types of relationships between these: entity/entity relationships, property/property relationships, and entity/property relationships, property/value relationships, and value/value relationships. The relationships can be of type dependency, choice, or compound.
4 |
5 | ## Primary and Secondary Entities
6 |
7 | For the purpose of navigation of the graph, it may be useful to define a primary entity. This entity is the starting point for subsequent operations. The identifier of the entity may be considered the identifier for the *record*. All other entities are secondary.
8 |
9 | * Main entity (0 or 1)
10 | * Secondary entities (0 or unlimited)
11 |
12 | Entities can be identified using RDF types (classes) or through specific properties.
13 |
14 | [Note: assume that cardinality can be used throughout, even if not expressly listed.]
15 |
16 | ## Stand alone
17 |
18 | In the Dublin Core Description Set Profile there is a quality called "stand alone" for entities which is either true or false. This determines whether an entity can exist without being the object of some other entity. "False" is is a broader requirement than a dependency because it does not state a dependency on any particular other entity in the set. "True" would allow, for example, that there could be entities for persons even though they are not associated with a specific resource. This could also be useful in allowing entities to be created at a convenient point in the workflow without triggering errors before the description is completed.
19 |
20 | ## Properties
21 |
22 | Once the entity/property and property/property relationships are applied, there can be rules that apply to the properties and their values:
23 | * property cardinality (if not already defined in relationship patterns)
24 | * property value rules
25 |
26 | ## Entity/entity relationships
27 |
28 | * Dependency:
29 | * if A then B / if A then not B
30 | * if A then (pattern), e.g. if A then (B or C), if A then (B and (C or D)), etc.
31 | * Choice
32 | * one of (list), not one of (list)
33 |
34 | ## Entity/property relationships
35 |
36 | * Dependency
37 | * if E1 then P1, if E1 then (patterns of P)
38 | * Choice
39 | * one of (list), not one of (list)
40 |
41 | ## Property/property relationships
42 |
43 | * Dependency:
44 | * if A then B / if A then not B
45 | * if A then (pattern), e.g. if A then (B or C), if A then (B and (C or D)), etc.
46 | * value of A / relationship / value of B (greater than, less than, equal to)
47 | * Choice
48 | * one of (list), not one of (list)
49 | * Compound
50 | * A and B must both be present
51 |
52 | ## Property/value relationships
53 |
54 | There will be many tests that can be done on property values, including ones with dependencies and choices. Some are enumerated here.
55 |
56 | | Property value | must/must not|
57 | | -------------- | ------------ |
58 | | value type | |
59 | | value list (choice) | |
60 | | value pattern (regex) | |
61 |
62 | ## Value/value relationships
63 |
64 | * greater than/less than
65 | * birth date must be less than death date
66 |
67 | ## Open/Closed
68 |
69 | The overall validation may require that the rules be closed, that is, that only the entities and properties in the Application Profile may be present. The presence of other entities or properties will be flagged as an error. [There will need to be a default of either open or closed that can be over-ridden.]
70 |
--------------------------------------------------------------------------------
/prior_art/blendingDoc.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: blendingDoc
3 | date: '2017-09-01T16:21:09+01:00'
4 | description:
5 | draft: false
6 | creators: []
7 | contributors: []
8 | publisher:
9 | tags: []
10 | aliases:
11 | - "/mediawiki_wiki/RDF_Application_Profiles/blendingDoc.html"
12 | ---
13 |
14 | **This is an archived MediaWiki page.**
15 | This page was last modified on 15 June 2015, at 19:18.
16 | This page has been accessed 7,543 times.
17 |
18 | # Blending DCAM, DCAP, DSP, & SHACL
19 |
20 | ## Discussion paper
21 |
22 | **Authors:** Karen Coyle, Corey Harper, & Tom Johnson
23 |
24 | **Date:** June 14, 2015
25 |
26 | The DCMI RDF Application Profiles Task Group [1] has been closely following the SHACL specification being developed by the W3C RDF Data Shapes Working Group [2]. SHACL is focused on RDF Validation, and is largely being implemented in SPARQL. This note attempts to distinguish between issues relating to RDF Validation and those relating to DC Application Profiles (DCAP), contending that the first are a subset of the second.
27 |
28 | RDF Validation takes a defined input Graph and determines whether it meets a particular set of well‐defined constraints. This is one of at least four functions of an Application Profile:
29 |
30 | 1. Define and assemble the triples that make up a Graph functioning as an information management entity in the context of an application;
31 | 2. Determine whether that specific Graph meets particular RDF validation criteria;
32 | 3. Validate related non‐RDF content referenced within that Graph according to external requirements (i.e Cryptographic Hash Function, XML Schema Validation, etc.);
33 | 4. Provide human readable documentation of the information management workflows related to the above three functions.
34 |
35 | From a recent discussion on the W3C Group’s Mailing List[3], it appears that SHACL will not address the question of assembling triples from multiple sources into a coherent Graph during validation, instead taking the view that a validation accepts an arbitrary Graph as input. This approach has the benefit that validations may be defined as independent from any particular assumptions about Graph scope. However, it implies that _1_ above needs to be handled externally and prior to SHACL validation and other validation techniques.
36 |
37 | We consider that the separation between RDF Validation and the other concerns is appropriate. Increasingly, we see a continued role for DCAP in providing a framework for managing selected Graphs as mutable information sources. In this view:
38 |
39 | - Dublin Core adopts SHACL to specify and validate Graph contents, but not the sources or composition of Graphs themselves;
40 | - SHACL subsumes the DSP notions of Description Templates and Statement Templates, handling the definition of constraints and validation against those constraints. This represents the majority of concepts defined in the DCMI DSP document;[4]
41 | - The graph selection process is related to the Dublin Core Abstract Model (DCAM).[5] [6]
42 |
43 | Much of the the ongoing gathering of DCMI RDF AP requirements[7] has been related to SHACL and validation, though some have addressed graph selection. We urge the DCMI Task Group take as a next step identifying which requirements address validation and can be covered by SHACL, and which are better understood as Application Profile functions. A gap analysis would build on ongoing work to map DC requirements to SHACL. Combined with a DCAM revised for RDF 1.1, this will clarify the role of Application Profiles and their relationship to SHACL.
44 |
45 | ## References
46 |
47 | 1 [/mediawiki_wiki/RDF‐Application‐Profiles](/mediawiki_wiki/RDF%E2%80%90Application%E2%80%90Profiles)
48 |
49 | 2 [https://www.w3.org/2014/data-shapes/wiki/Main\_Page](https://www.w3.org/2014/data-shapes/wiki/Main_Page)
50 |
51 | 3 [http://lists.w3.org/Archives/Public/public‐data‐shapes‐wg/2015Jun/0023.html](http://lists.w3.org/Archives/Public/public%E2%80%90data%E2%80%90shapes%E2%80%90wg/2015Jun/0023.html)
52 |
53 | 4 [http://dublincore.org/documents/dc‐dsp/](http://dublincore.org/documents/dc%E2%80%90dsp/)
54 |
55 | 5 [http://dublincore.org/documents/abstract‐model/](http://dublincore.org/documents/abstract%E2%80%90model/)
56 |
57 | 6 [/mediawiki_wiki/Review\_of\_DCMI\_Abstract\_Model](/mediawiki_wiki/Review_of_DCMI_Abstract_Model)
58 |
59 | 7 [http://lelystad.informatik.uni‐mannheim.de/rdf‐validation/?q=requirements/dc‐requirements](http://lelystad.informatik.uni%E2%80%90mannheim.de/rdf%E2%80%90validation/?q=requirements/dc%E2%80%90requirements)
60 |
61 |
--------------------------------------------------------------------------------
/prior_art/readme.md:
--------------------------------------------------------------------------------
1 | # Prior Art
2 |
3 | Place here documents from related prior and ongoing activities in the area of profiles.
4 |
5 | There is a [wiki page](https://github.com/dcmi/dcap/wiki/Related-Projects) with information about related work including links.
6 |
7 |
--------------------------------------------------------------------------------
/prior_art/singapore-framework.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/dcmi/dcap/a3a3f0dcda84179e9624df3a75b9277bd8d00cb7/prior_art/singapore-framework.png
--------------------------------------------------------------------------------
/prior_art/sinopiaProfile.json:
--------------------------------------------------------------------------------
1 | {
2 | "$schema": "http://json-schema.org/draft-07/schema#",
3 | "$id": "https://ld4p.github.io/sinopia/schemas/0.0.9/profile.json",
4 | "type": "object",
5 | "title": "Sinopia Profile Schema",
6 | "description": "Profile, or array of Resource Templates with some top-level metadata.",
7 | "version": "0.0.9",
8 | "required": [ "Profile" ],
9 | "additionalProperties": false,
10 | "properties": {
11 | "Profile": {
12 | "type": "object",
13 | "title": "Profile" ,
14 | "description": "Profile key always at top level of a Sinopia Profile.",
15 | "required": [
16 | "author",
17 | "date",
18 | "description",
19 | "id",
20 | "resourceTemplates",
21 | "schema",
22 | "title"
23 | ],
24 | "additionalProperties": false,
25 | "properties": {
26 | "adherence": {
27 | "type": "string",
28 | "title": "Adherence",
29 | "description": "The standards or rules that this profile adheres to.",
30 | "example": [
31 | "PCC",
32 | "PCC RDA Working Group"
33 | ]
34 | },
35 | "author": {
36 | "type": "string",
37 | "title": "Author",
38 | "description": "Contact information associated with the profile.",
39 | "minLength": 2,
40 | "example": [
41 | "PCC",
42 | "Michelle Futornick",
43 | "Cornell University Cataloging Department"
44 | ]
45 | },
46 | "date": {
47 | "type": "string",
48 | "format": "date",
49 | "title": "Date",
50 | "description": "Date associated with the profile",
51 | "minLength": 4,
52 | "example": [
53 | "2017-05-20"
54 | ]
55 | },
56 | "description": {
57 | "type": "string",
58 | "title": "Description",
59 | "description": "Textual description associated with the profile.",
60 | "minLength": 3,
61 | "example": [
62 | "Metadata for BIBFRAME Resources"
63 | ]
64 | },
65 | "id": {
66 | "type": "string",
67 | "title": "Identifier",
68 | "description": "Unique identifier associated with the profile. Eventually, a Profile URI.",
69 | "minLength": 3,
70 | "example": [
71 | "profile:bf2:AdminMetadata",
72 | "http://sinopia.io/resources/common/AdminMetadataProfile"
73 | ]
74 | },
75 | "remark": {
76 | "type": "string",
77 | "title": "Remark",
78 | "description": "Comment or guiding statement intended to be presented as supplementary information in user display.",
79 | "example": [
80 | "Title information relating to a resource: work title, preferred title, instance title, transcribed title, translated title, variant form of title, etc."
81 | ]
82 | },
83 | "resourceTemplates": {
84 | "$ref": "https://ld4p.github.io/sinopia/schemas/0.0.9/resource-templates-array.json"
85 | },
86 | "schema": {
87 | "const": "https://ld4p.github.io/sinopia/schemas/0.0.9/profile.json",
88 | "title": "URL for Profile's JSON schema",
89 | "description": "The profile adheres to the JSON schema at this URL",
90 | "minLength": 8,
91 | "example": [
92 | "https://ld4p.github.io/sinopia/schemas/0.0.9/profile.json"
93 | ]
94 | },
95 | "source": {
96 | "type": "string",
97 | "format": "uri",
98 | "title": "Source URI",
99 | "description": "URL or URI for the profile in the author's source repository or space.",
100 | "example": [
101 | "https://raw.githubusercontent.com/LD4P/sinopia_sample_profiles/master/profiles/v0.0.9/BIBFRAME%202.0%20Agents.json"
102 | ]
103 | },
104 | "title": {
105 | "type": "string",
106 | "title": "Title",
107 | "description": "Textual title associated with the profile.",
108 | "minLength": 3,
109 | "example": [
110 | "BIBFRAME 2.0 Agents"
111 | ]
112 | }
113 | }
114 | }
115 | }
116 | }
117 |
--------------------------------------------------------------------------------
/profile/vocabulary.md:
--------------------------------------------------------------------------------
1 | # Dublin Core Application Profile - Model and Vocabulary
2 |
3 | **Date:**
4 | August 21, 2020
5 |
6 | **Status:**
7 | Draft - Request for Comments
8 |
9 | **Editors:**
10 | Karen Coyle
11 |
12 | **Contributors**
13 | Tom Baker, DCMI
14 | Phil Barker
15 | John Huck, University of Alberta
16 | Ben Reisenberg, University of Washington
17 |
18 |
19 | ## Introduction
20 |
21 | This is a first draft of a vocabulary for simple application profiles, as developed by the Dublin Core Metadata Initiative community. This draft is not considered to be complete although it may be sufficient for some purposes. The draft assumes that the profile defines the rules for instance data in RDF, although it may also be useful for other data formats.
22 |
23 | There is often confusion about the "meta" levels when talking about profiles and metadata. This vocabulary is used to define a *profile*, which is a description and set of rules that can be used to create input interfaces with rules and constraints, or validation processes that operate over existing data. The contents of the profile are not the same as the contents of instance data.
24 |
25 | ## Model
26 |
27 | The Dublin Core application profile has a simple basic structure.
28 |
29 | Each profile consists of:
30 |
31 | * Zero or more entities with
32 | * one or more statements
33 |
34 | Each entity in the profile is described with:
35 |
36 | * one entity identifier
37 | * zero or one label
38 |
39 | Each statement consists of:
40 |
41 | * one property identifier
42 | * zero or one label
43 | * zero or one boolean statement for cardinality "Mandatory"
44 | * zero or one boolean statement for cardinality "Repeatable"
45 | * zero or one value type
46 | * zero or one annotation
47 | * zero or one referral to an entity defined in the profile
48 |
49 | Not yet included in this model, but intended to be added by the working group are the following additions to the statement:
50 |
51 | * RDF node type
52 | * Value constraint type
53 | * Value constraint
54 |
55 | ## Vocabulary
56 | ### Entity
57 | **entityID** - an identifier for the entity description in the profile. May be global or local. The entityID is required if the profile will describe a specified entity
58 |
59 | * cardinality: per entity - mandatory, not repeatable
60 | * datatype: IRI (recommended) or local identifier
61 |
62 | **entityLabel**- a human-facing label for the entity that can be used in documentation and displays. See [label]
63 |
64 | * cardinality: optional, repeatable if a language string
65 | * datatype: xsd:string | rdf:langString
66 |
67 | ### Statement
68 | **propertyID** - propertyID - for the RDF-based profile, the property ID must be the IRI of a vocabulary term that is defined elsewhere in RDF, RDFS, or OWL.
69 |
70 | * cardinality: per property - mandatory, not repeatable
71 | * datatype: IRI
72 |
73 | **propertyLabel** - a human-facing label for the entity that can be used in documentation and displays. See [label]
74 |
75 | * cardinality: optional, repeatable if a language string or: if there are property labels in multiple languages
76 | * datatype: string
77 |
78 | **mandatory** - is the property mandatory? a boolean (yes/no)
79 |
80 | * cardinality: optional, not repeatable
81 | * datatype: Boolean
82 |
83 | **repeatable** - is the property repeatable? a boolean (yes/no)
84 |
85 | * cardinality: optional, not repeatable
86 | * datatype: Boolean
87 |
88 | **entityShapeReference** - provides a link when the value of a property is a reference to an entity in the profile.
89 |
90 | *cardinality: optional, not repeatable
91 | *datatype: string, matching entityID value
92 |
93 | **annotation** - free text area for any further information relating to the property or its usage
94 |
95 | * cardinality: optional, not repeatable
96 | * datatype: string
97 |
98 | ### Note on labels
99 |
100 | Labels are short texts intended to be read by human beings, to be displayed at any point where the profile will be viewed. If the profile serves an audience with a single natural language choice, the label is a single string of one or a few words. For communities that cross languages and wish to have the displays match the language of the viewer, the RDF [langString](https://www.w3.org/TR/rdf-schema/#ch_langstring) data type is used. See the User Guide (link) for input rules.
101 |
102 |
103 |
104 |
--------------------------------------------------------------------------------
/prototypes/bookCase1/Template_for_documentation.csv:
--------------------------------------------------------------------------------
1 | Entity_ID,Property,Value,ValueType,Cardinality,Property_Label,Annotation
2 | book,dct:creator,@person,entity,"0,-1",Author,Value to be validated as a person entity
3 | ,dct:title,,literal,"1,1",Title,
4 | ,dct:date,,date,"1,1",Date,Use form: YYYY-MM-DD
5 | person,foaf:name,,literal,"1,1",Name,Use form: FirstName LastName
6 | ,foaf:mbox,,URI,"0,1",Email,Use form: mbox:foo@bar.org
7 |
--------------------------------------------------------------------------------
/prototypes/bookCase1/Template_for_instance_data.csv:
--------------------------------------------------------------------------------
1 | Entity_ID,Property,Value
2 | book,dct:creator,entity:person
3 | ,dct:title,Flower arranging simplified
4 | ,dct::date,xsd:2017
5 | person,foaf:name,John Smith
6 | ,foaf:mbox,mbox:john@example.org
7 |
--------------------------------------------------------------------------------
/prototypes/bookcaseEG/bookCaseEG.ods:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/dcmi/dcap/a3a3f0dcda84179e9624df3a75b9277bd8d00cb7/prototypes/bookcaseEG/bookCaseEG.ods
--------------------------------------------------------------------------------
/prototypes/bookcaseEG/bookCaseEG.xls:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/dcmi/dcap/a3a3f0dcda84179e9624df3a75b9277bd8d00cb7/prototypes/bookcaseEG/bookCaseEG.xls
--------------------------------------------------------------------------------
/prototypes/bookcaseEG/ex3.yaml:
--------------------------------------------------------------------------------
1 | %YAML 1.1
2 | ---
3 | value:
4 |
5 | - &value_literal_3_250
6 | valueID: value_literal_3_250
7 | dataType: literal
8 | minLength: 3
9 | maxLength: 250
10 |
11 | - &value2
12 | valueID: value2
13 | dataType: literal
14 |
15 | - &value3
16 | valueID: value3
17 | dataType: xsd:mbox
18 |
19 | statement:
20 |
21 | - &title
22 | statementID: title
23 | displayName: Title
24 | value : *value_literal_3_250
25 |
26 | - &name
27 | statementID: name
28 | displayName: Name
29 | value: *value2
30 |
31 | - &homepage
32 | statementID: homepage
33 | displayName: Homepage
34 | value: *value3
35 |
36 | description:
37 |
38 | - &book
39 | descID: book
40 | displayName: Book
41 | statements:
42 | - << : *title
43 | minOccur : 1
44 | maxOccur : 1
45 |
46 | - &creator
47 | descID: creator
48 | displayName: Creator
49 | statements:
50 | - << : *name
51 | minOccur : 1
52 | maxOccur : -1
53 | - << : *homepage
54 | minOccur : 0
55 | maxOccur : 1
56 |
57 | descriptionSet:
58 |
59 | descSetID: 123
60 | descriptions : [*book, *creator]
61 |
--------------------------------------------------------------------------------
/prototypes/bookcaseEG/readme.md:
--------------------------------------------------------------------------------
1 | #Book case example
2 |
3 | This example uses multiple tabs in a spreadsheet so it cannot be easily rendered in csv.
4 |
--------------------------------------------------------------------------------
/prototypes/bookclub/README.md:
--------------------------------------------------------------------------------
1 | # Book Club
2 | Application profile for a simple bookclub in CSV and ShEx,with some conformant instance data
3 |
4 | Basic idea is that in addition to basic info about books, there is some social network info about who owns them and which owners know to each other.
5 |
6 | ## bookclubEgs.csv
7 |
8 | This is a single file with four different variations on the book club example.
9 |
10 | 1. This is a transcription of Phil's file ap.csv, but using the current columns and column headers. I believe that this version does not fulfill the use case because it defines a dependency between books and members; a dataset with one book and one member that have no links between them cannot be defined with this version.
11 | 2. This table has a row for the shape that includes cardinality on the shape; otherwise it is the same as 1. It isn't clear if this can be validated in this format using RDF validation.
12 | 3. The third table uses a "manifest" method to define book and member as shapes within the book club, with desired cardinality.
13 | 4. The fourth table is based on #1 but does not change the cardinality commitment of shapes; it does demonstrate a possibly more readable style using a row for the shape above the row(s) for properties.
14 | 5. This table includes unique classes for Book and for Member, which can be tested for their presence within a single file or dataset.
15 |
16 | ## Sample instance data
17 |
18 | ### data.ttl
19 |
20 | Original file; all books and members are connected.
21 |
22 | ### data2.ttl
23 |
24 | Based on data.ttl, one member added that is not the object of any triples in the file.
25 |
26 | ### bookclubeg1.ttl
27 |
28 | One book, one author, one member.
29 | * Book has arc to author
30 | * Book has arc to member
31 | * Member has arc to book
32 |
33 | ### bookclubeg2.ttl
34 |
35 | Same as bookclubeg1.ttl except adds one member with no arc to book, and no arc from book.
36 |
37 | ### bookclubeg3.ttl
38 |
39 | Similar to bookclubeg2.ttl, but has manifest connecting books and members; one member has no arc back to book.
40 |
41 |
--------------------------------------------------------------------------------
/prototypes/bookclub/ap.csv:
--------------------------------------------------------------------------------
1 | ID,URI,Label,Mandatory,Repeatable,Type,Value Space,Comment
2 | sdo:,http://schema.org/,schema.org,,,,,
3 | foaf:,http://xmlns.com/foaf/,FOAF,,,,,
4 | wd:,http://www.wikidata.org/entity/,Wikidata Entities,,,,,
5 | wdt:,http://www.wikidata.org/prop/direct/,Wikidata Properties,,,,,
6 | xsd:,http://www.w3.org/2001/XMLSchema#,XML Schema,,,,,
7 | rdf:,http://www.w3.org/1999/02/22-rdf-syntax-ns#,RDF,,,,,
8 | ,,,,,,,
9 | @book,,Book,y,y,,,
10 | ,rdf:type,instance of,y,n,URI,sdo:Book,must be schema.org/Book
11 | ,rdf:type,instance of,y,n,URI,wd:Q571,must be wikidata Book
12 | ,sdo:name,title,y,n,Literal,xsd:string,
13 | ,sdo:author,author,y,y,URI,@author,
14 | ,wdt:P127,owner,y,y,URI,@owner,owned by
15 | ,,,,,,,
16 | @author,,Author,,,,,
17 | ,rdf:type,instance of,y,n,URI,sdo:Person sdo:Organization,must be person or organization
18 | ,sdo:givenName,given name,y,n,Literal,xsd:string,
19 | ,sdo:familyName,family name,n,n,Literal,xsd:string,
20 | ,,,,,,,
21 | @owner,,Owner,,,,,
22 | ,rdf:type,instance of,y,n,URI,sdo:Person,
23 | ,rdf:type,instance of,y,n,URI,foaf:Person,
24 | ,sdo:givenName,given name,y,n,Literal,xsd:string,
25 | ,sdo:familyName,family name,y,n,Literal,xsd:string,
26 | ,foaf:knows,friend of,n,y,URI,@owner,
--------------------------------------------------------------------------------
/prototypes/bookclub/bookclubEg1Label.csv:
--------------------------------------------------------------------------------
1 | 1,,,,,,,,,,
2 | shapeID,property,Label,Mandatory,Repeatable,valueType,literalValueType,shapeRef,constraintType,constraint,Annotation
3 | book,,Book,,,,,,,,
4 | ,rdf:type,instance of,y,n,URI,,,,sdo:Book,must be schema.org/Book
5 | ,rdf:type,instance of,y,n,URI,,,,wd:Q571,must be wikidata Book
6 | ,sdo:name,title,y,n,Literal,xsd:string,,,,
7 | ,sdo:author,author,y,y,URI,,author,,,URI or bnode?
8 | ,wdt:P127,owner,n,y,URI,,member,,,URI or bnode?
9 | ,,,,,,,,,,
10 | author,,Author,,,,,,,,
11 | ,rdf:type,instance of,y,n,URI,,,,sdo:Person sdo:Organization,must be person or organization/rdf would be union
12 | ,sdo:givenName,given name,y,n,Literal,xsd:string,,,,
13 | ,sdo:familyName,family name,n,n,Literal,xsd:string,,,,
14 | ,,,,,,,,,,
15 | member,,Member,,,,,,,,
16 | ,rdf:type,instance of,y,n,URI,,,,sdo:Person,
17 | ,rdf:type,instance of,y,n,URI,,,,foaf:Person,
18 | ,sdo:givenName,given name,y,n,Literal,xsd:string,,,,
19 | ,sdo:familyName,family name,y,n,Literal,xsd:string,,,,
20 | ,foaf:knows,friend of,n,y,URI,,member,,,
21 | ,ex:owns,owns book,n,y,URI,,book,,,
22 | 2,,,,,,,,,,
23 | shapeID,property,Label,Mandatory,Repeatable,valueType,literalValueType,shapeRef,constraintType,constraint,Annotation
24 | book,,Book,,,,,,,,
25 | book,rdf:type,instance of,y,n,URI,,,,sdo:Book,must be schema.org/Book
26 | book,rdf:type,instance of,y,n,URI,,,,wd:Q571,must be wikidata Book
27 | book,sdo:name,title,y,n,Literal,xsd:string,,,,
28 | book,sdo:author,author,y,y,URI,,author,,,URI or bnode?
29 | book,wdt:P127,owner,n,y,URI,,member,,,URI or bnode?
30 | ,,,,,,,,,,
31 | author,,Author,,,,,,,,
32 | author,rdf:type,instance of,y,n,URI,,,,sdo:Person sdo:Organization,must be person or organization/rdf would be union
33 | author,sdo:givenName,given name,y,n,Literal,xsd:string,,,,
34 | author,sdo:familyName,family name,n,n,Literal,xsd:string,,,,
35 | ,,,,,,,,,,
36 | member,,Member,,,,,,,,
37 | member,rdf:type,instance of,y,n,URI,,,,sdo:Person,
38 | member,rdf:type,instance of,y,n,URI,,,,foaf:Person,
39 | member,sdo:givenName,given name,y,n,Literal,xsd:string,,,,
40 | member,sdo:familyName,family name,y,n,Literal,xsd:string,,,,
41 | member,foaf:knows,friend of,n,y,URI,,member,,,
42 | member,ex:owns,owns book,n,y,URI,,book,,,
43 |
--------------------------------------------------------------------------------
/prototypes/bookclub/bookclubEg2Label.csv:
--------------------------------------------------------------------------------
1 | 3,,,,,,,,,,,
2 | shapeID,shapeLabel,propID,propLabel,Mandatory,Repeatable,valueType,literalValueType,shapeRef,constraintType,constraint,Annotation
3 | book,Book,,,,,,,,,,
4 | ,,rdf:type,instance of,y,n,URI,,,,sdo:Book,must be schema.org/Book
5 | ,,rdf:type,instance of,y,n,URI,,,,wd:Q571,must be wikidata Book
6 | ,,sdo:name,title,y,n,Literal,xsd:string,,,,
7 | ,,sdo:author,author,y,y,URI,,author,,,URI or bnode?
8 | ,,wdt:P127,owner,n,y,URI,,member,,,URI or bnode?
9 | ,,,,,,,,,,,
10 | 4,,,,,,,,,,,
11 | shapeID,shapeLabel,propID,propLabel,Mandatory,Repeatable,valueType,literalValueType,shapeRef,constraintType,constraint,Annotation
12 | book,Book,rdf:type,instance of,y,n,URI,,,,sdo:Book,must be schema.org/Book
13 | book,,rdf:type,instance of,y,n,URI,,,,wd:Q571,must be wikidata Book
14 | book,,sdo:name,title,y,n,Literal,xsd:string,,,,
15 | book,,sdo:author,author,y,y,URI,,author,,,URI or bnode?
16 | book,,wdt:P127,owner,n,y,URI,,member,,,URI or bnode?
17 | member,,Member,sdo:familyName,family name,y,n,Literal,xsd:string,,,
18 | member,,foaf:knows,friend of,n,y,URI,,member,,,
19 | member,,ex:owns,owns book,n,y,URI,,book,,,
20 |
--------------------------------------------------------------------------------
/prototypes/bookclub/bookclubeg1.ttl:
--------------------------------------------------------------------------------
1 | @prefix ex: .
2 | @prefix sdo: .
3 | @prefix wd: .
4 | @prefix wdt: .
5 |
6 |
7 | ex:123
8 | a sdo:Book ;
9 | a wd:Q571 ;
10 | sdo:name "Moby Dick" ;
11 | sdo:author _:b1 ;
12 | wdt:P127 _:b2
13 | .
14 |
15 | _:b1
16 | a sdo:Person ;
17 | sdo:givenName "Herman" ;
18 | sdo:familyName "Melville"
19 | .
20 | _:b2
21 | a sdo:Person ;
22 | a foaf:Person ;
23 | sdo:givenName "Mary" ;
24 | sdo:familyName "Reader" ;
25 | foaf:knows _:b5 ;
26 | ex:owns ex:123 .
27 |
--------------------------------------------------------------------------------
/prototypes/bookclub/bookclubeg2.ttl:
--------------------------------------------------------------------------------
1 | @prefix ex: .
2 | @prefix sdo: .
3 | @prefix wd: .
4 | @prefix wdt: .
5 | @prefix foaf: .
6 |
7 | ex:123
8 | a sdo:Book ;
9 | a wd:Q571 ;
10 | sdo:name "Moby Dick" ;
11 | sdo:author _:b1 ;
12 | wdt:P127 _:b2
13 | .
14 |
15 | _:b1
16 | a sdo:Person ;
17 | sdo:givenName "Herman" ;
18 | sdo:familyName "Melville"
19 | .
20 | _:b2
21 | a sdo:Person ;
22 | a foaf:Person ;
23 | sdo:givenName "Mary" ;
24 | sdo:familyName "Reader" ;
25 | foaf:knows _:b5 ;
26 | ex:owns ex:123 .
27 |
28 | ex:789
29 | a sdo:Person ;
30 | a foaf:Person ;
31 | sdo:givenName "Fred" ;
32 | sdo:familyName "Flintstone" .
33 |
--------------------------------------------------------------------------------
/prototypes/bookclub/bookclubeg3.ttl:
--------------------------------------------------------------------------------
1 | @prefix ex: .
2 | @prefix sdo: .
3 | @prefix wd: .
4 | @prefix wdt: .
5 | @prefix foaf: .
6 |
7 | ex:abc
8 | ex:hasBook ex:123 ;
9 | ex:hasMember
10 | _:b2 ,
11 | _:b5 ,
12 | ex:789
13 | .
14 |
15 | ex:123
16 | a sdo:Book ;
17 | a wd:Q571 ;
18 | sdo:name "Moby Dick" ;
19 | sdo:author _:b1 ;
20 | wdt:P127 _:b2
21 | .
22 |
23 | _:b1
24 | a sdo:Person ;
25 | sdo:givenName "Herman" ;
26 | sdo:familyName "Melville"
27 | .
28 | _:b2
29 | a sdo:Person ;
30 | a foaf:Person ;
31 | sdo:givenName "Mary" ;
32 | sdo:familyName "Reader" ;
33 | foaf:knows _:b5 ;
34 | ex:owns ex:123 .
35 |
36 | ex:789
37 | a sdo:Person ;
38 | a foaf:Person ;
39 | sdo:givenName "Fred" ;
40 | sdo:familyName "Flintstone" .
41 |
--------------------------------------------------------------------------------
/prototypes/bookclub/data.ttl:
--------------------------------------------------------------------------------
1 | @prefix book: .
2 | @prefix member: .
3 | @prefix author: .
4 | @prefix wd: .
5 | @prefix wdt: .
6 | @prefix sdo: .
7 | @prefix foaf: .
8 | @prefix xsd: .
9 |
10 | book:001 a sdo:Book, wd:Q571 ;
11 | sdo:name "The Human Factor" ;
12 | sdo:author author:001 ;
13 | wdt:P127 member:001 , member:002 . # owned by
14 |
15 | book:002 a sdo:Book, wd:Q571 ;
16 | sdo:name "The Comedians" ;
17 | sdo:author author:001 ;
18 | wdt:P127 member:002 . # owned by
19 |
20 | author:001 a sdo:Person ;
21 | sdo:givenName "Graham" ;
22 | sdo:familyName "Greene" .
23 |
24 | member:001 a sdo:Person, foaf:Person ;
25 | sdo:givenName "Greg" ;
26 | sdo:familyName "Arious" ;
27 | foaf:knows member:002 .
28 |
29 | member:002 a sdo:Person, foaf:Person ;
30 | sdo:givenName "Billy" ;
31 | sdo:familyName "No Mates" .
32 |
--------------------------------------------------------------------------------
/prototypes/bookclub/data2.ttl:
--------------------------------------------------------------------------------
1 | @prefix book: .
2 | @prefix member: .
3 | @prefix author: .
4 | @prefix wd: .
5 | @prefix wdt: .
6 | @prefix sdo: .
7 | @prefix foaf: .
8 | @prefix xsd: .
9 |
10 | book:001 a sdo:Book, wd:Q571 ;
11 | sdo:name "The Human Factor" ;
12 | sdo:author author:001 ;
13 | wdt:P127 member:001 , member:002 . # owned by
14 |
15 | book:002 a sdo:Book, wd:Q571 ;
16 | sdo:name "The Comedians" ;
17 | sdo:author author:001 ;
18 | wdt:P127 member:002 . # owned by
19 |
20 | author:001 a sdo:Person ;
21 | sdo:givenName "Graham" ;
22 | sdo:familyName "Greene" .
23 |
24 | member:001 a sdo:Person, foaf:Person ;
25 | sdo:givenName "Greg" ;
26 | sdo:familyName "Arious" ;
27 | foaf:knows member:002 .
28 |
29 | member:002 a sdo:Person, foaf:Person ;
30 | sdo:givenName "Billy" ;
31 | sdo:familyName "No Mates" .
32 |
33 | member:003 a sdo:Person, foaf:Person ;
34 | sdo:givenName "Mary" ;
35 | sdo:familyName "No Mates" .
--------------------------------------------------------------------------------
/prototypes/data1.json:
--------------------------------------------------------------------------------
1 | {
2 | "entityID": "12345",
3 | "entityLabel": "Book",
4 | "entityDescription": "This is the entity for the book",
5 | "APproperties": {
6 | "APpropertyName": "MARC 245",
7 | "APpropertyLabel": "Main title",
8 | "APpropertyDescription": "This is the main title for the book"
9 | }
10 |
11 | }
12 |
--------------------------------------------------------------------------------
/prototypes/painting/E130.csv:
--------------------------------------------------------------------------------
1 | Entity_name,Entity_label,Property,Property_label,Cardinality,Value,Value_type,Annotation
2 | painting,Painting,wdt:P31,Is a,1..1,wd:Q3305213,URI,"instance of ""painting"""
3 | ,,wdt:P571,Date of inception,0..1,,DateTime,
4 | ,,wdt:P276,Location,1..-1,,,
5 | ,,wdt:P1476,Title,1..-1,,,
6 | ,,wdt:P195,Collection,1..-1,,,
7 | ,,wdt:P170,Creator,1..-1,creator,Entity_name,
8 | creator,Artist,wdt:P31,Is a,1..1,wd:,URIStem,"instance of ""creator"""
9 |
--------------------------------------------------------------------------------
/prototypes/painting/E130.shexc:
--------------------------------------------------------------------------------
1 | # https://www.wikidata.org/wiki/EntitySchema:E130
2 | PREFIX wd:
3 | PREFIX wdt:
4 | PREFIX xsd:
5 |
6 | start = @
7 |
8 | {
9 | # instance of painting
10 | wdt:P31 [wd:Q3305213] ;
11 | # inception
12 | wdt:P571 xsd:dateTime ? ;
13 | # location
14 | wdt:P276 . + ;
15 | # title
16 | wdt:P1476 . + ;
17 | # collection
18 | wdt:P195 . + ;
19 | # creator
20 | wdt:P170 @+
21 | }
22 |
23 | {
24 | wdt:P31 [wd:~] ;
25 | }
26 |
27 | # Proposed test for SPARQL - Top 25 paintings
28 | # SELECT ?id WHERE { VALUES ?id { wd:Q12418 wd:Q45585 wd:Q175036 wd:Q29530 wd:Q185372 wd:Q219831 wd:Q151047 wd:Q208758 wd:Q25729 wd:Q154469 wd:Q474338 wd:Q328523 wd:Q321303 wd:Q1892745 wd:Q334138 wd:Q1091086 wd:Q698487 wd:Q212616 wd:Q152509 wd:Q152867 wd:Q220859 wd:Q734834 } }
29 |
--------------------------------------------------------------------------------
/prototypes/painting/E130.shexj:
--------------------------------------------------------------------------------
1 | {
2 | "type": "Schema",
3 | "start": "https://rawgit.com/shexSpec/shex.js/master/packages/shex-webapp/doc/painting",
4 | "shapes": [
5 | {
6 | "type": "Shape",
7 | "id": "https://rawgit.com/shexSpec/shex.js/master/packages/shex-webapp/doc/creator",
8 | "expression": {
9 | "type": "TripleConstraint",
10 | "predicate": "http://www.wikidata.org/prop/direct/P31",
11 | "valueExpr": {
12 | "type": "NodeConstraint",
13 | "values": [
14 | {
15 | "type": "IriStem",
16 | "stem": "http://www.wikidata.org/entity/"
17 | }
18 | ]
19 | }
20 | }
21 | },
22 | {
23 | "type": "Shape",
24 | "id": "https://rawgit.com/shexSpec/shex.js/master/packages/shex-webapp/doc/painting",
25 | "expression": {
26 | "type": "EachOf",
27 | "expressions": [
28 | {
29 | "type": "TripleConstraint",
30 | "predicate": "http://www.wikidata.org/prop/direct/P31",
31 | "valueExpr": {
32 | "type": "NodeConstraint",
33 | "values": [
34 | "http://www.wikidata.org/entity/Q3305213"
35 | ]
36 | }
37 | },
38 | {
39 | "type": "TripleConstraint",
40 | "predicate": "http://www.wikidata.org/prop/direct/P571",
41 | "valueExpr": {
42 | "type": "NodeConstraint",
43 | "datatype": "http://www.w3.org/2001/XMLSchema#dateTime"
44 | },
45 | "min": 0,
46 | "max": 1
47 | },
48 | {
49 | "type": "TripleConstraint",
50 | "predicate": "http://www.wikidata.org/prop/direct/P276",
51 | "min": 1,
52 | "max": -1
53 | },
54 | {
55 | "type": "TripleConstraint",
56 | "predicate": "http://www.wikidata.org/prop/direct/P1476",
57 | "min": 1,
58 | "max": -1
59 | },
60 | {
61 | "type": "TripleConstraint",
62 | "predicate": "http://www.wikidata.org/prop/direct/P195",
63 | "min": 1,
64 | "max": -1
65 | },
66 | {
67 | "type": "TripleConstraint",
68 | "predicate": "http://www.wikidata.org/prop/direct/P170",
69 | "valueExpr": "https://rawgit.com/shexSpec/shex.js/master/packages/shex-webapp/doc/creator",
70 | "min": 1,
71 | "max": -1
72 | }
73 | ]
74 | }
75 | }
76 | ],
77 | "@context": "http://www.w3.org/ns/shex.jsonld"
78 | }
79 |
--------------------------------------------------------------------------------
/prototypes/painting/E130.shexj_generated:
--------------------------------------------------------------------------------
1 | {
2 | "type": "Schema",
3 | "start": "https://rawgit.com/shexSpec/shex.js/master/packages/shex-webapp/doc/painting",
4 | "shapes": [
5 | {
6 | "type": "Shape",
7 | "id": "https://rawgit.com/shexSpec/shex.js/master/packages/shex-webapp/doc/creator",
8 | "expression": {
9 | "type": "TripleConstraint",
10 | "predicate": "http://www.wikidata.org/prop/direct/P31",
11 | "valueExpr": {
12 | "type": "NodeConstraint",
13 | "values": [
14 | {
15 | "type": "IriStem",
16 | "stem": "http://www.wikidata.org/entity/"
17 | }
18 | ]
19 | }
20 | }
21 | },
22 | {
23 | "type": "Shape",
24 | "id": "https://rawgit.com/shexSpec/shex.js/master/packages/shex-webapp/doc/painting",
25 | "expression": {
26 | "type": "EachOf",
27 | "expressions": [
28 | {
29 | "type": "TripleConstraint",
30 | "predicate": "http://www.wikidata.org/prop/direct/P31",
31 | "valueExpr": {
32 | "type": "NodeConstraint",
33 | "values": [
34 | "http://www.wikidata.org/entity/Q3305213"
35 | ]
36 | }
37 | },
38 | {
39 | "type": "TripleConstraint",
40 | "predicate": "http://www.wikidata.org/prop/direct/P571",
41 | "valueExpr": {
42 | "type": "NodeConstraint",
43 | "datatype": "http://www.w3.org/2001/XMLSchema#dateTime"
44 | },
45 | "min": 0,
46 | "max": 1
47 | },
48 | {
49 | "type": "TripleConstraint",
50 | "predicate": "http://www.wikidata.org/prop/direct/P276",
51 | "min": 1,
52 | "max": -1
53 | },
54 | {
55 | "type": "TripleConstraint",
56 | "predicate": "http://www.wikidata.org/prop/direct/P1476",
57 | "min": 1,
58 | "max": -1
59 | },
60 | {
61 | "type": "TripleConstraint",
62 | "predicate": "http://www.wikidata.org/prop/direct/P195",
63 | "min": 1,
64 | "max": -1
65 | },
66 | {
67 | "type": "TripleConstraint",
68 | "predicate": "http://www.wikidata.org/prop/direct/P170",
69 | "valueExpr": "https://rawgit.com/shexSpec/shex.js/master/packages/shex-webapp/doc/creator",
70 | "min": 1,
71 | "max": -1
72 | }
73 | ]
74 | }
75 | }
76 | ],
77 | "@context": "http://www.w3.org/ns/shex.jsonld"
78 | }
79 |
--------------------------------------------------------------------------------
/prototypes/painting/E130.xlsx:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/dcmi/dcap/a3a3f0dcda84179e9624df3a75b9277bd8d00cb7/prototypes/painting/E130.xlsx
--------------------------------------------------------------------------------
/prototypes/painting/E130b.csv:
--------------------------------------------------------------------------------
1 | Entity_name,Property,Property_label,Mand,Repeat,Value,Value_type,Annotation
2 | painting,wdt:P31,Is a,yes,no,wd:Q3305213,URI,"Instance of ""painting"""
3 | ,wdt:P571,Date of inception,no,no,,DateTime,
4 | ,wdt:P276,Location,yes,yes,,,
5 | ,wdt:P1476,Title,yes,yes,,,
6 | ,wdt:P195,Collection,yes,yes,,,
7 | ,wdt:P170,Creator,yes,yes,creator,Entity_name,
8 | creator,wdt:P31,Is a,yes,no,wd:,URIStem,
9 |
--------------------------------------------------------------------------------
/prototypes/painting/E130b.xlsx:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/dcmi/dcap/a3a3f0dcda84179e9624df3a75b9277bd8d00cb7/prototypes/painting/E130b.xlsx
--------------------------------------------------------------------------------
/prototypes/painting/profile2Instance1.csv:
--------------------------------------------------------------------------------
1 | Entity_name,Entity_label,Property,Property_label,Cardinality,Value,Value_type,Annotation
2 | book,Book,dct:creator,Author,0..-1,person,entity,Author is not required; no limit on the number
3 | ,,dct:title,Title,1..1,,literal,Each book must have a title
4 | ,,dct:date,Year of publication,1..1,,xsd:year,"Only the year, 9999"
5 | person,Person,foaf:Name,Name,1..1,,literal,Each person has one name
6 | ,,foaf:mbox,Email,0..1,,URI,Email is optional but only one allowed
7 | ,,dct:date,Birth year,0..1,,xsd:year,"Only the year, 9999"
--------------------------------------------------------------------------------
/prototypes/painting/readme.md:
--------------------------------------------------------------------------------
1 | # Profile for Painting in Wikidata
2 |
3 | **out of date with dctap**
4 |
5 | This directory shows a profile based on E130, the Wikidata schema for "Painting". It includes a jupiter notebook for converting the CSV file to ShEx.
6 |
--------------------------------------------------------------------------------
/prototypes/readme.md:
--------------------------------------------------------------------------------
1 | # Prototypes directory
2 |
3 | This is a directory for experiments and prototypes of profiles. If you have profiles to submit you can email them to the list, ask on the email list to be added to the group of people who can submit files to this repo. Thank you!
4 |
5 | There may be some more organization of this directory and clearer naming of prototypes.
6 |
7 | In general, prototype should have:
8 | * a template file that is a template for profiles;
9 | * one or more instances of profiles
10 |
11 | The prototypes may also show instance data that conforms to the profile, but we have recognized that the same template will NOT generate the profile instance and the instance data.
12 |
13 | ## Minimal profile templates
14 |
15 | ### [Wikidata example](wikidata_painting)
16 |
17 | Presented at DCMI 2019, this prototype has a simple, one "spreadsheet" csv file as input, and uses a program (available in a Jupyter notebook) to convert the file to the Wikidata Entity Schema format that is expressed in ShEx.
18 |
19 | ### [Book Case in YAML](templateYAML)
20 |
21 | 1. bookCaseEG.xls
22 | 1. bookCaseEG.ods
23 | 1. bookCaseEG.yaml
24 |
25 | This does not (yet) have a profile template file; however, a template for this model . The YAML file makes use of entities and values that have identifiers and are each "called" from the higher entity level (e.g. description entity "calls" statement entities). The spreadsheet file (.xls or .ods) uses a separate sheet for each identified entity.
26 |
27 | ### [One-sheet spreadsheet template](bookCase1)
28 |
29 | 1. Template_for_documentation.csv
30 | 1. Template_for_instance_data.csv
31 |
32 | A simple template similar to the profile2 template. The valueType is general (e.g. entity, literal, uri). It has a position for an entity value.
33 |
34 | ### [One-sheet spreadsheet from Hackathon](simpleFromHackathon)
35 |
36 | 1. profile2Template.csv
37 | 1. profile2Instance.csv
38 |
39 | The template file is similar to the one-sheet one above but with some modifications made during the Hackathon. Each row represents an entity, a statement, and a value constraint.
40 |
41 | ### [Simple](Simple profile)
42 |
43 | This profile has been updated as the group has made decisions, and becomes the basis for milestone 1 of the group's work. Not all of the files will be carried over.
44 |
45 | ## Extended profile templates
46 |
47 | ### [Extended Template in JSON](extendedTemplateInJSON)
48 |
49 | This is based on the fuller schema described in [simpleSchema.csv](/simpleSchema.csv) of Sep 2019
50 | * [data1.json](prototypes/data1.json) (Sep 2019)
51 | * [schema1.json](prototypes/schema1.json) (Sep 2019)
52 | * [schema2.json](prototypes/extendedTemplateInJSON/schema2.json) (Nov 2019)
53 | * [sinopiaProfile.json](prior_art/sinopiaProfile.json) (Apr 2019)
54 |
--------------------------------------------------------------------------------
/prototypes/recipe/README.md:
--------------------------------------------------------------------------------
1 | # Recipe
2 | Attempt to represent the [Google guided recipe guidelines](https://developers.google.com/search/docs/data-types/recipe) as an application profile of schema.org recipe.
3 |
--------------------------------------------------------------------------------
/prototypes/recipe/ap_recipe.csv:
--------------------------------------------------------------------------------
1 | ID,URI,Label,Type,Value Space,Mandatory,Repeatable,Comment,
2 | ,,,,,,,based on https://developers.google.com/search/docs/data-types/recipe,It would be useful to have a way of adding comments about the AP as a whole
3 | sdo:,http://schema.org/,,,,,,,
4 | rdf:,http://www.w3.org/1999/02/22-rdf-syntax-ns#,RDF,,,,,,
5 | xsd:,http://www.w3.org/2001/XMLSchema#,XML Schema,,,,,,
6 | ,,,,,,,,
7 | @Recipe,,Recipe,,,y,n,Application profile for a single recipe,
8 | ,rdf:type,instance of,URI ,sdo:Recipe,y,n,,
9 | ,sdo:image,image, ,xsd:anyURI @Image,y,y,Image of the completed dish.,? how to say Type is URI or Entitiy depending on which Value space is used
10 | ,sdo:name,name,Literal,xsd:string,y,n,The name of the dish.,
11 | ,sdo:url,page URL,URI ,xsd:anyURI,n,n,The URL of the recipe's web page,not in the Google requirements b/c metadata is assumed to be on-page
12 | ,sdo:aggregateRating,,Entity,@AggregateRating,n,n,,
13 | ,sdo:author,,Entity,@Author,n,y,,
14 | ,sdo:cookTime,,Literal,xsd:duration,n,n,Use ISO 8601 duration format,is there a better RDF construct for ISO 8601
15 | ,sdo:datePublished,,Literal,xsd:date,n,n,,
16 | ,sdo:description,,Literal,xsd:string,n,n,,
17 | ,sdo:keywords,,Literal,xsd:string,n,y,,
18 | ,sdo:nutrition,,Entity,@NutritionInformation,n,n,,?only use if recipe yield is specified
19 | ,sdo:prepTime,,Literal,xsd:duration,n,n,,
20 | ,sdo:recipeCategory,,Literal,xsd:string,n,y,,
21 | ,sdo:recipeCuisine,,Literal,xsd:string,n,y,,
22 | ,sdo:recipeIngredient,,Literal,xsd:string,y,y,,
23 | ,sdo:recipeInstructions,,,@HowToStep @HowToSection xsd:string,y,n,,required for guided recipes
24 | ,sdo:recipeYield,,Literal,xsd:string,n,n,,
25 | ,sdo:totalTime,,Literal,xsd:duration,n,n,,
26 | ,sdo:video,,Entity,@Video,n,y,,
27 | ,,,,,,,,
28 | @Image,,Image Object,,,,,,
29 | ,rdf:type,instance of,URI ,sdo:ImageObject,y,n,,
30 | ,sdo:contentUrl,location,URI ,xsd:anyURI,y,n,,
31 | ,sdo:caption,image caption,Literal,xsd:string,n,n,,
32 | ,,,,,,,,
33 | @AggregateRating,,Rating,,,,,,
34 | ,rdf:type,instance of,URI,sdo:AggregateRating,y,n,,
35 | ,sdo:itemReviewed,,URI,,y,n,,? hmm. should point back to recipe ID/url; but is nesting enough?
36 | ,sdo:ratingCount,,Literal,xsd:integer,y,n,The total number of ratings,? either this or the next property is required
37 | ,sdo:reviewCount,,Literal,xsd:integer,y,n,Specifies the number of people who provided a review with or without an accompanying rating.,
38 | ,sdo:ratingValue,,Literal,xsd:float xsd:string,y,n,"The aggregate rating, e.g. 4.1 or 82%",
39 | ,sdo:bestRating,,Literal,xsd:float,n,n,The best rating possible,
40 | ,sdo:worstRating,,Literal,xsd:float,n,n,The worst rating possible,
41 | ,,,,,,,,
42 | @Author,,Recipe Author,,,,,The name of the person or organization that wrote the recipe.,
43 | ,rdf:type,instance of,URI ,sdo:Person :Organization,y,n,,
44 | ,sdo:name,Name,Literal,xsd:string,y,y,,
45 | ,,,,,,,,
46 | @NutritionInformation,,Nutritional Information,,,,,,
47 | ,rdf:type,instance of,URI,sdo:NutritionInformation,y,n,,
48 | ,sdo:calories,,Literal,xsd:string,y,n,Energy per serving in form e.g. 420kCal,
49 | ,sdo:servingSize,,Literal,xsd:string,y,n,,
50 | ,,,,,,,,
51 | @HowToSection,,Set of instructions,,,,,,
52 | ,rdf:type,instance of ,URI,sdo:HowToSection,y,n,,
53 | ,sdo:name,title for this section,Literal,xsd:string,y,n,,
54 | ,sdo:text,summary of this section,Literal,xsd:string,y,n,,
55 | ,sdo:itemListElement,instruction,,@HowToStep,y,y,,
56 | ,sdo:itemListOrder,,URI,sdo:ItemListOrderAscending,y,n,,
57 | ,,,,,,,,
58 | @HowToStep,,Instruction step,,,,,,
59 | ,rdf:type,,URI,sdo:HowToStep,y,n,,
60 | ,sdo:name,heading for instructions,Literal,xsd:string,y,n,,
61 | ,sdo:text,detailed instructions,Literal,xsd:string,n,n,,
62 | ,sdo:url,link to this step,URI,,n,y,,
63 | ,sdo:image,image(s) for this step,,xsd:anyURI @image,n,y,,
64 | ,sdo:video,a video of this step,Entity,@Video,,,,
65 | ,,,,,,,,
66 | @Video,,Image Object,,,,,,
67 | ,rdf:type,instance of,URI ,sdo:VideoObject,y,n,,
68 | ,sdo:name,,,xsd:string,y,n,,
69 | ,sdo:contentUrl,location,URI ,xsd:anyURI,y,n,,
70 | ,sdo:embedUrl,,URI ,xsd:anyURI,y,y,,
71 | ,sdo:url,,URI ,xsd:anyURI,y,n,,
72 | ,sdo:hasPart,A clip from a video,Entity,@VideoObject,n,y,,
73 | ,sdo:thumbnailUrl,,URI ,xsd:anyURI,n,n,,
74 | ,sdo:startOffset,The start of a clip,Literal,xsd:integer,n,n,Required for clips,
75 | ,sdo:endOffset,The end of a clip,Literal,xsd:integer,n,n,Required for clips,
--------------------------------------------------------------------------------
/prototypes/recipe/guided_recipe.json:
--------------------------------------------------------------------------------
1 |
2 | {
3 | "@context": "https://schema.org/",
4 | "@type": "Recipe",
5 | "name": "Party Coffee Cake",
6 | "image": [
7 | "https://example.com/photos/1x1/photo.jpg",
8 | "https://example.com/photos/4x3/photo.jpg",
9 | "https://example.com/photos/16x9/photo.jpg"
10 | ],
11 | "author": {
12 | "@type": "Person",
13 | "name": "Mary Stone"
14 | },
15 | "datePublished": "2018-03-10",
16 | "description": "This coffee cake is awesome and perfect for parties.",
17 | "prepTime": "PT20M",
18 | "cookTime": "PT30M",
19 | "totalTime": "PT50M",
20 | "keywords": "cake for a party, coffee",
21 | "recipeYield": "10",
22 | "recipeCategory": "Dessert",
23 | "recipeCuisine": "American",
24 | "nutrition": {
25 | "@type": "NutritionInformation",
26 | "calories": "270 calories"
27 | },
28 | "recipeIngredient": [
29 | "2 cups of flour",
30 | "3/4 cup white sugar",
31 | "2 teaspoons baking powder",
32 | "1/2 teaspoon salt",
33 | "1/2 cup butter",
34 | "2 eggs",
35 | "3/4 cup milk"
36 | ],
37 | "recipeInstructions": [
38 | {
39 | "@type": "HowToStep",
40 | "name": "Preheat",
41 | "text": "Preheat the oven to 350 degrees F. Grease and flour a 9x9 inch pan.",
42 | "url": "https://example.com/party-coffee-cake#step1",
43 | "image": "https://example.com/photos/party-coffee-cake/step1.jpg"
44 | },
45 | {
46 | "@type": "HowToStep",
47 | "name": "Mix dry ingredients",
48 | "text": "In a large bowl, combine flour, sugar, baking powder, and salt.",
49 | "url": "https://example.com/party-coffee-cake#step2",
50 | "image": "https://example.com/photos/party-coffee-cake/step2.jpg"
51 | },
52 | {
53 | "@type": "HowToStep",
54 | "name": "Add wet ingredients",
55 | "text": "Mix in the butter, eggs, and milk.",
56 | "url": "https://example.com/party-coffee-cake#step3",
57 | "image": "https://example.com/photos/party-coffee-cake/step3.jpg"
58 | },
59 | {
60 | "@type": "HowToStep",
61 | "name": "Spread into pan",
62 | "text": "Spread into the prepared pan.",
63 | "url": "https://example.com/party-coffee-cake#step4",
64 | "image": "https://example.com/photos/party-coffee-cake/step4.jpg"
65 | },
66 | {
67 | "@type": "HowToStep",
68 | "name": "Bake",
69 | "text": "Bake for 30 to 35 minutes, or until firm.",
70 | "url": "https://example.com/party-coffee-cake#step5",
71 | "image": "https://example.com/photos/party-coffee-cake/step5.jpg"
72 | },
73 | {
74 | "@type": "HowToStep",
75 | "name": "Enjoy",
76 | "text": "Allow to cool and enjoy.",
77 | "url": "https://example.com/party-coffee-cake#step6",
78 | "image": "https://example.com/photos/party-coffee-cake/step6.jpg"
79 | }
80 | ],
81 | "aggregateRating": {
82 | "@type": "AggregateRating",
83 | "ratingValue": "5",
84 | "ratingCount": "18"
85 | },
86 | "video": {
87 | "@type": "VideoObject",
88 | "name": "How to make a Party Coffee Cake",
89 | "description": "This is how you make a Party Coffee Cake.",
90 | "thumbnailUrl": [
91 | "https://example.com/photos/1x1/photo.jpg",
92 | "https://example.com/photos/4x3/photo.jpg",
93 | "https://example.com/photos/16x9/photo.jpg"
94 | ],
95 | "contentUrl": "http://www.example.com/video123.mp4",
96 | "embedUrl": "http://www.example.com/videoplayer?video=123",
97 | "uploadDate": "2018-02-05T08:00:00+08:00",
98 | "duration": "PT1M33S",
99 | "interactionStatistic": {
100 | "@type": "InteractionCounter",
101 | "interactionType": { "@type": "http://schema.org/WatchAction" },
102 | "userInteractionCount": 2347
103 | },
104 | "expires": "2019-02-05T08:00:00+08:00"
105 | }
106 | }
107 |
--------------------------------------------------------------------------------
/prototypes/schema1.json:
--------------------------------------------------------------------------------
1 |
2 | {
3 | "$schema": "http://json-schema.org/schema#",
4 | "$id": "http://dcapexample.com/apPropertySchema.json",
5 | "type": "object",
6 | "properties": {
7 | "APpropertyID": {
8 | "type": "string",
9 | "description": "URI for the property",
10 | "pattern": "(regex for URI here)"
11 | },
12 | "APpropertyName": {
13 | "type": "string",
14 | "description": "A metadata element name that is not a URI."
15 | },
16 | "APpropertyLabel": {
17 | "type": "string",
18 | "description": "A brief display label for the property. If using RDF-style language strings, only one label per language should be used"
19 | },
20 |
21 | "APpropertyDescription": {
22 | "type": "string",
23 | "description": "A description of the property at whatever length is needed"
24 | }
25 | },
26 | "type": "object",
27 | "properties": {
28 | "entityID": {
29 | "type": "string",
30 | "description": "URI for the entity"
31 | },
32 | "entityLabel": {
33 | "type": "string",
34 | "description": "A brief display label for the entity. If using RDF-style language strings, only one label per language should be used"
35 | },
36 |
37 | "entityDescription": {
38 | "type": "string",
39 | "description": "A description of the entity at whatever length is needed"
40 | }
41 |
42 | }
43 | }
44 |
--------------------------------------------------------------------------------
/prototypes/simple/definitions.md:
--------------------------------------------------------------------------------
1 | # Definitions
2 |
3 | ## Entity
4 | A resource being described, and which is identified by the Entity_name
5 |
6 | ## Entity_label
7 | A human-friendly text representing the entity that can be used in displays and documentation
8 |
9 | ## Property
10 | An identifier for a single metadata statement about an entity
11 |
12 | ## Property_label
13 | A human-friendly text representing the property that can be used in displays and documentation
14 |
15 | ## Mandatory
16 | A yes/no value (alternatively 1/0, T/F) indicating whether a property is required or is optional in instance data describing a single entity
17 |
18 | ## Repeatable
19 | A yes/no value (alternatively 1/0, T/F) indicating whether a property may be used only once or more than once in instance data describing a single entity
20 |
21 | ## Value_type
22 | The data type of the value in the instance data for the related property. It is assumed that each property has a value
23 |
24 | ## Value
25 | Specific constraints on the value beyond the Value_type. This can include the Entity_label for an entity as value, URI name-space constraints for values limited to certain lists of entities, or other (as yet undefined here) value constraints
26 |
27 | ## Annotation
28 | Any text that gives information about the property and value in the profile
29 |
30 |
31 | # Tables of elements
32 |
33 | | simple1 | simple2
34 | | --- | ---
35 | |Entity_name|Entity_name|
36 | |Entity_label|Entity_label|
37 | |Statement_ID| |
38 | |Property|Property|
39 | |Property_Label|Property_label|
40 | |Cardinality|Mand|
41 | ||Repeat|
42 | ||Value|
43 | Value_type|Value_type|
44 | Annotation|Annotation|
45 |
46 |
--------------------------------------------------------------------------------
/prototypes/simple/explainer.csv:
--------------------------------------------------------------------------------
1 | entityID,entityLabel,propertyID,propertyLabel,mandatory,repeatable,valueDataType,entityIDReference,annotation
2 |
--------------------------------------------------------------------------------
/prototypes/simple/formalisms.md:
--------------------------------------------------------------------------------
1 | # Formalizing the simple profile
2 |
3 | 2020-04-10: Edited here and synced with https://github.com/dcmi/dcap/blob/master/prototypes/simple/formalisms.md
4 |
5 | We need sufficient formalization to allow the creation of input and validation programs. The assumption here is the [simple](https://github.com/dcmi/dcap/tree/master/prototypes/simple) prototype that we have agreed on as the basic "core".
6 |
7 | In essence, the below is the template for the profile template. It is necessary to think "meta" here.
8 |
9 |
10 | ## General statement of rules
11 | A Profile MUST have at least one property.
12 | A Profile MAY have one or more entities defined with unique identifiers.
13 |
14 |
15 |
16 | ## Elements of the profile template
17 |
18 | ### Entity_name (EntityID?)
19 | cardinality: 0,n
20 | Datatype: string | IRI | BNODE
21 | Default: none
22 |
23 | The entity is a thing or concept being described by the metadata. Entity is optional because we have decided that one could have a profile with an assumed single entity. If this is absent then no entity is defined. There can be more than one entity in the profile, and each must have a unique entity name. Although this is called "name" it is an identifier and may be an IRI.
24 |
25 | ### Entity_label
26 | cardinality 0,1
27 | Datatype: string | languageString
28 | Default: none
29 |
30 | The entity label exists *only* if there is an entity. It is optional. If language-tagged strings are used there is one label per tagged language allowed. This can be considered = skos:prefLabel
31 |
32 | ## Property
33 | Cardinality: 1,n
34 | ? Change name to Property_ID?
35 | Datatype: IRI
36 | Default: none
37 |
38 | If there are one or more entities, properties are subordinated to specific entities. Otherwise, the properties in the profile are properties of an unnamed single entity. This element identifies the property and must be unique within the profile.
39 |
40 | ### Property_label
41 | Cardinality: 0,1
42 | Datatype: string | languageString
43 |
44 | The same rules apply here as for the Entity_label regarding the desire to specify one per language tag.
45 |
46 | ### Mandatory
47 | Cardinality: 0,1
48 | Datatype: binary
49 | Default: 0
50 |
51 | A binary field*. If not coded, no rules regarding "mandatory" can be applied. This probably means that the default is "not mandatory".
52 |
53 | * We have to decide what values are accepted for a binary field, such as "0/1" "T/F" "Yes/No"
54 |
55 | ### Repeatable
56 | Cardinality: 0,1
57 | Datatype: binary
58 | Default: 1
59 |
60 | A binary field. If not coded, no rules regarding repeatability can be applied. This probably means that the default is "repeatable".
61 |
62 | ### Value_type
63 | Cardinality: 0,1
64 | Datatype: IRI?
65 | Default: string
66 |
67 | I'm not sure if this should be 1,1 or 0,1 with a default. If there is a default, it should be literal ("text" in the ContentMD examples). Although there are many possible content types, if this is left entirely open in terms of values interoperability will be harmed. We should probably develop at least one pick-list with standard value types that we think will be needed. There could be a "core" list that is a subset of a more ample list. IRIs for type standards should be encouraged.
68 |
69 | ### Value (constraint?)
70 | Cardinality: 0,1
71 | Datatype: ?
72 | Default: none
73 |
74 | This is an element for additional constraints on the value beyond simple value data type. This could be: a pick list of literal values; one or more IRI stems; minimum and maximum length for strings (?); etc.
75 |
76 | It's hard to know what to call this, but the concept is pretty clear.
77 |
78 | ### Annotation
79 | Cardinality: 0,1
80 | Datatype: string | languageString
81 | Default: none
82 |
83 | As there is one annotation column for each property in the template, this is at the property level and can provide additional information on the property or the specific value constraints. This element is wide open in terms of content. It will probably be a text field in most cases. If there is a lot to say about the property then this can be lengthy. Because we are looking at a tabular format there is a limit of one per row (which corresponds to the definition of a property and its value). As with other literal fields, we need to decide how to handle language literals.
84 |
--------------------------------------------------------------------------------
/prototypes/simple/readme.md:
--------------------------------------------------------------------------------
1 | # Simple template
2 |
3 | These documents are for the simple profile that is being proposed. This is based on the template developed for the [Wikidata schema](/prototypes/wikidata_painting) prototype. This is very similar to the simple profile developed at the DCMI 2019 [Hackathon](/prototypes/simpleFromHackathon).
4 |
5 | This includes the [template](simpleTemplate.csv) and proposed [definitions](definitions.md).
6 |
7 | There is an experimental [ShEx](shex4simple.txt) document that *might* express the simple profile in ShEx.
8 |
--------------------------------------------------------------------------------
/prototypes/simple/shex4simple.txt:
--------------------------------------------------------------------------------
1 | PREFIX :
2 | PREFIX xsd:
3 | PREFIX rdfs:
4 |
5 | # ShEx validation for simple profile
6 | # blank = 1,1
7 | # + = 1,n
8 | # * = 0, n
9 | # ? = 0, 1
10 |
11 | start = @
12 |
13 | { # A Profile has:
14 | :EntityShape @* ; # optional entity shape, repeatable
15 | :Property @+ # one or more PropertyShape(s)
16 | }
17 |
18 | {
19 | :EntityShapeID IRI; # if entity, required, not repeatable
20 | :EntityLabel LITERAL?; # optional, not repeatable
21 | :Property @+ # required for profile, repeatable
22 | }
23 |
24 | { # A Property has:
25 | :PropertyID IRI ; # required identifier, IRI (for RDF profile)
26 | :PropertyLabel [xsd:string rdfs:langString]* ; # an optional label, not repeatable
27 | :Mandatory ["y" "n"]? ; # optional, maximum 1
28 | :Repeatable ["y" "n"]? ; # optional, maximum 1
29 | :ValueType ["IRI" "LITERAL" "BNODE"]? ; # The general value type, optional, not repeatable
30 | :ValueDataType IRI? ; # optional, not repeatable; preference to xsd types
31 | :ValueConstraint xsd:string? ; # additional value constraints; optional, not repeatable
32 | :EntityShapeReference Nonliteral? ; # A reference to an entity in the profile; optional, not repeatable
33 | :Annotation xsd:string* ; # any information needed about property + value; optional, repeatable
34 | }
35 |
--------------------------------------------------------------------------------
/prototypes/simple/simpleInstance.csv:
--------------------------------------------------------------------------------
1 | shapeID,shapeLabel,propertyID,propertyLabel,mandatory,repeatable,valueNodeType,valueDataType,valueConstraint,valueConstraintType,valueShape,note
2 | book,Book,dct:creator,Author,y,y,,,,,person,Author is not required; no limit on the number
3 | ,,dct:title,Title,y,n,,literal,,,,Each book must have a title
4 | ,,dct:date,Year of publication,y,n,,xsd:year,,,,Only the year - 9999
5 | person,Person,foaf:Name,Name,y,n,,literal,,,,Each person has one name
6 | ,,foaf:mbox,Email,n,y,,URI,,,,Email is optional but only one allowed
7 | ,,dct:date,Birth year, n,y,,xsd:year,,,,Only the year - 9999
8 |
9 |
--------------------------------------------------------------------------------
/prototypes/simple/simpleTemplate.csv:
--------------------------------------------------------------------------------
1 | shapeID,shapeLabel,propertyID,propertyLabel,mandatory,repeatable,valueNodeType,valueDataType,valueConstraint,valueConstraintType,valueShape,note
2 |
--------------------------------------------------------------------------------
/prototypes/simpleFromHackathon/profile2Instance1.csv:
--------------------------------------------------------------------------------
1 | Entity_name,Entity_label,Statement_ID,Property,Property_Label,Cardinality,Value_type,Annotation
2 | book,Book,creator,dct:creator,Author,"0,-1",@person,"Author is not required; no limit on the number"
3 | ,,title,dct:title,Title,"1,1",literal,"Each book must have a title"
4 | ,,pubDate,dct:date,Year of publication,"1,1",xsd:year,"Only the year, 9999"
5 | person,Person,name,foaf:Name,Name,"1,1",literal,"Each person has one name"
6 | ,,email,foaf:mbox,Email,"0,1",URI,"Email is optional but only one allowed"
7 | ,,birthDate,dct:date,Birth year, "0,1",xsd:year,"Only the year, 9999"
8 |
--------------------------------------------------------------------------------
/prototypes/simpleFromHackathon/profile2Template.csv:
--------------------------------------------------------------------------------
1 | Entity_name,Entity_label,Statement_ID,Property,Property_Label,Cardinality,Value_type,Annotation
2 |
--------------------------------------------------------------------------------
/prototypes/simpleFromHackathon/readme.md:
--------------------------------------------------------------------------------
1 | # Simple template
2 |
3 | This is the template that was developed at the Hackathon in Seoul, the DCMI 2019 meeting.
4 | This greatly reduced the template to key elements that could be included on a single
5 | spreadsheet row.
6 |
7 | 1. Template_for_documentation.csv
8 | 1. Template_for_instance_data.csv
9 |
10 | A simple template similar to the profile2 template. The valueType is general (e.g. entity, literal, uri). It has a position for an entity value.
11 |
--------------------------------------------------------------------------------
/prototypes/simple_w_headers/readme.md:
--------------------------------------------------------------------------------
1 | This [example](simple_w_headers/w_headers) contains headers that show which columns belong to the entity description and which to the property.
2 |
3 |
--------------------------------------------------------------------------------
/prototypes/simple_w_headers/w_headers.csv:
--------------------------------------------------------------------------------
1 | Entity Description Template,,Statement Template,,,,,,,,,,
2 | Entity-ID,Entity Label,Property Constraints,,Value Constraints,,,,,,,Cardinality,
3 | ,,Property Label,Prefixed Property URI,Value Kind,Value Entity-Ref,Value URI,Value String,Value List,String Language,String Datatype,Min,Max
4 | book,Book,Creator,dcterms:creator,bnode,creator,,,,,,1,1
5 | creator,Creator,Name,foaf:name,literal,,,,,,,1,-1
6 | ,,Homepage,foaf:homepage,uri,,,,,,,0,1
7 |
--------------------------------------------------------------------------------
/prototypes/simpler/contentDMeg1.md:
--------------------------------------------------------------------------------
1 | Note, this is taken from the [University of Washington](https://www.lib.washington.edu/cams/mig/advice) ContentDM documentation. The fields below are only a selection from their metadata profile. Two of the data elements, "hidden" and "searchable" are not ones that we have considered in the past, but could be seen as elements of an application profile since they are application specific. The remaining two fields are "Big field" (which is a statement about the maximum size of the value) and "ControlVoc" (whether it takes a controlled vocabulary). Both of these are specifications about the value.
2 |
3 | ContentDM elements
4 |
5 | | Field name | DC mapping | Data type |
6 | | ------| ------| ------
7 | | Title | Title | Text |
8 | | Subject |Subject | Text |
9 | | Description | Description | Text |
10 | | Creator | Creator | Text |
11 | | Publisher | Publisher |Text |
12 | | Date | Date | Text|
13 |
14 | DCAP elements
15 |
16 | | Property_label | Property | Value_type|
17 | | ------| ------| ------|
18 | | Title | dc:title | Text|
19 | | Subject |dc:subject | Text|
20 | | Description | dc:description | Text |
21 | | Creator | dc:creator | Text |
22 | | Publisher | dc:publisher |Text |
23 | | Date | dc:date | Text |
24 |
--------------------------------------------------------------------------------
/prototypes/templateYAML/bookCaseEG.ods:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/dcmi/dcap/a3a3f0dcda84179e9624df3a75b9277bd8d00cb7/prototypes/templateYAML/bookCaseEG.ods
--------------------------------------------------------------------------------
/prototypes/templateYAML/bookCaseEG.yaml:
--------------------------------------------------------------------------------
1 | %YAML 1.1
2 | ---
3 | value:
4 |
5 | - &value_literal_3_250
6 | valueID: value_literal_3_250
7 | dataType: literal
8 | minLength: 3
9 | maxLength: 250
10 |
11 | - &value2
12 | valueID: value2
13 | dataType: literal
14 |
15 | - &value3
16 | valueID: value3
17 | dataType: xsd:mbox
18 |
19 | statement:
20 |
21 | - &title
22 | statementID: title
23 | displayName: title
24 | value : *value_literal_3_250
25 |
26 | - &name
27 | statementID: name
28 | displayName: Name
29 | value: *value2
30 |
31 | - &homepage
32 | statementID: homepage
33 | displayName: Homepage
34 | value: *value3
35 |
36 | description:
37 |
38 | - &book
39 | descID: book
40 | displayName: Book
41 | statements:
42 | - << : *title
43 | minOccur : 1
44 | maxOccur : 1
45 |
46 | - &creator
47 | descID: creator
48 | displayName: Creator
49 | statements:
50 | - << : *name
51 | minOccur : 1
52 | maxOccur : -1
53 | - << : *homepage
54 | minOccur : 0
55 | maxOccur : 1
56 |
57 | descriptionSet:
58 |
59 | descSetID: 123
60 | descriptions : [*book, *creator]
61 |
--------------------------------------------------------------------------------
/prototypes/templateYAML/readme.md:
--------------------------------------------------------------------------------
1 | # Example in YAML
2 |
3 | 1. bookCaseEG.xls
4 | 1. bookCaseEG.ods
5 | 1. bookCaseEG.yaml
6 |
7 | This does not (yet) have a profile template file; however, a template for this model . The YAML file makes use of entities and values that have identifiers and are each "called" from the higher entity level (e.g. description entity "calls" statement entities). The spreadsheet file (.xls or .ods) uses a separate sheet for each identified entity.
8 |
--------------------------------------------------------------------------------
/prototypes/wikidata_hospital/readme.md:
--------------------------------------------------------------------------------
1 | ## Wikidata hospital example
2 |
3 | This example is taken from John Samuel's more terse [version](https://github.com/johnsamuelwrites/ShExStatements/blob/master/examples/wikidata/hospital.csv).
4 | KCoyle has added headers to it. Eventually it would be good to add the labels to the WD identifiers.
5 |
--------------------------------------------------------------------------------
/prototypes/wikidata_hospital/wdHospitalvSimple.csv:
--------------------------------------------------------------------------------
1 | ,Karen's rewriting of @hospital,,,,,,,
2 | ,,,,,,,,
3 | ID,URI,Label,Value Type,Value,Mandatory,Repeatable,Comment,
4 | wd,,,,,,,,
5 | wdt,,,,,,,,
6 | xsd,,,,,,,,
7 | ,,,,,,,,
8 | @hospital,wdt:P31,is a,URI,wd:Q16917,y,n,instance of a hospital,
9 | @hospital,wdt:P17,country,URISTEM,wd:,y,n,Country in which the hospital is located,
10 | @hospital,wdt:P131,located in administrative territorial entity,URISTEM,wd:,y,y,City, state or other administrative unit; can be repeated
11 | @hospital,wdt:P625,geographical coordinates,,,y,y,,
12 | @hospital,wdt:P856,web site,URI,,n,y,The primary hospital web site,
13 | @hospital,wdt:P1705,name in native language,LITERAL,,n,y,,
14 | @hospital,wdt:P6375,street address,LITERAL,,n,y,,
15 | @hospital,wdt:P571,inception date,xsd:year,,n,n,Date the hospital was founded; yyyy,
16 | ,,,,,,,,
17 | ,John S's original ,,,,,,,
18 | ,https://github.com/johnsamuelwrites/ShExStatements/blob/master/examples/wikidata/hospital.csv,,,,,,,
19 | ,,,,,,,,
20 | wd,,,,,,,,
21 | wdt,,,,,,,,
22 | xsd,,,,,,,,
23 | ,,,,,,,,
24 | @hospital,EXTRA,wdt:P31,,,,,,
25 | ,,,,,,,,
26 | @hospital,wdt:P31,wd:Q16917,,# instance of a hospital,,,,
27 | @hospital,wdt:P17,0,1,#country,,,,
28 | @hospital,wdt:P131,0,1,#located in the administrative territorial entity,,,,
29 | @hospital,wdt:P625,0,0,#coordinate location,,,,
30 | @hospital,wdt:P856,0,*,#official website,,,,
31 | @hospital,wdt:P1705,0,*,#native label,,,,
32 | @hospital,wdt:P6375,0,*,#street address,,,,
33 |
--------------------------------------------------------------------------------
/prototypes/wikidata_hospital/wd_hospital.csv:
--------------------------------------------------------------------------------
1 | ID,URI,Value,Cardinality,Comment
2 | wd,,,,
3 | wdt,,,,
4 | xsd,,,,
5 | ,,,,
6 | @hospital,EXTRA,wdt:P31,,
7 | ,,,,
8 | @hospital,wdt:P31,wd:Q16917,,# instance of a hospital
9 | @hospital,wdt:P17,,1,#country
10 | @hospital,wdt:P131,,1,#located in the administrative territorial entity
11 | @hospital,wdt:P625,,+,#coordinate location
12 | @hospital,wdt:P856,,*,#official website
13 | @hospital,wdt:P1705,,*,#native label
14 | @hospital,wdt:P6375,,*,#street address
15 |
--------------------------------------------------------------------------------
/prototypes/wikidata_painting/E130.csv:
--------------------------------------------------------------------------------
1 | Entity_name,Entity_label,Property,Property_label,Cardinality,Value,Value_type,Annotation
2 | painting,Painting,wdt:P31,Is a,1..1,wd:Q3305213,URI,"instance of ""painting"""
3 | ,,wdt:P571,Date of inception,0..1,,DateTime,
4 | ,,wdt:P276,Location,1..-1,,,
5 | ,,wdt:P1476,Title,1..-1,,,
6 | ,,wdt:P195,Collection,1..-1,,,
7 | ,,wdt:P170,Creator,1..-1,creator,Entity_name,
8 | creator,Artist,wdt:P31,Is a,1..1,wd:,URIStem,"instance of ""creator"""
9 |
--------------------------------------------------------------------------------
/prototypes/wikidata_painting/E130.shexc:
--------------------------------------------------------------------------------
1 | # https://www.wikidata.org/wiki/EntitySchema:E130
2 | PREFIX wd:
3 | PREFIX wdt:
4 | PREFIX xsd:
5 |
6 | start = @
7 |
8 | {
9 | # instance of painting
10 | wdt:P31 [wd:Q3305213] ;
11 | # inception
12 | wdt:P571 xsd:dateTime ? ;
13 | # location
14 | wdt:P276 . + ;
15 | # title
16 | wdt:P1476 . + ;
17 | # collection
18 | wdt:P195 . + ;
19 | # creator
20 | wdt:P170 @+
21 | }
22 |
23 | {
24 | wdt:P31 [wd:~] ;
25 | }
26 |
27 | # Proposed test for SPARQL - Top 25 paintings
28 | # SELECT ?id WHERE { VALUES ?id { wd:Q12418 wd:Q45585 wd:Q175036 wd:Q29530 wd:Q185372 wd:Q219831 wd:Q151047 wd:Q208758 wd:Q25729 wd:Q154469 wd:Q474338 wd:Q328523 wd:Q321303 wd:Q1892745 wd:Q334138 wd:Q1091086 wd:Q698487 wd:Q212616 wd:Q152509 wd:Q152867 wd:Q220859 wd:Q734834 } }
29 |
--------------------------------------------------------------------------------
/prototypes/wikidata_painting/E130.shexj:
--------------------------------------------------------------------------------
1 | {
2 | "type": "Schema",
3 | "start": "https://rawgit.com/shexSpec/shex.js/master/packages/shex-webapp/doc/painting",
4 | "shapes": [
5 | {
6 | "type": "Shape",
7 | "id": "https://rawgit.com/shexSpec/shex.js/master/packages/shex-webapp/doc/creator",
8 | "expression": {
9 | "type": "TripleConstraint",
10 | "predicate": "http://www.wikidata.org/prop/direct/P31",
11 | "valueExpr": {
12 | "type": "NodeConstraint",
13 | "values": [
14 | {
15 | "type": "IriStem",
16 | "stem": "http://www.wikidata.org/entity/"
17 | }
18 | ]
19 | }
20 | }
21 | },
22 | {
23 | "type": "Shape",
24 | "id": "https://rawgit.com/shexSpec/shex.js/master/packages/shex-webapp/doc/painting",
25 | "expression": {
26 | "type": "EachOf",
27 | "expressions": [
28 | {
29 | "type": "TripleConstraint",
30 | "predicate": "http://www.wikidata.org/prop/direct/P31",
31 | "valueExpr": {
32 | "type": "NodeConstraint",
33 | "values": [
34 | "http://www.wikidata.org/entity/Q3305213"
35 | ]
36 | }
37 | },
38 | {
39 | "type": "TripleConstraint",
40 | "predicate": "http://www.wikidata.org/prop/direct/P571",
41 | "valueExpr": {
42 | "type": "NodeConstraint",
43 | "datatype": "http://www.w3.org/2001/XMLSchema#dateTime"
44 | },
45 | "min": 0,
46 | "max": 1
47 | },
48 | {
49 | "type": "TripleConstraint",
50 | "predicate": "http://www.wikidata.org/prop/direct/P276",
51 | "min": 1,
52 | "max": -1
53 | },
54 | {
55 | "type": "TripleConstraint",
56 | "predicate": "http://www.wikidata.org/prop/direct/P1476",
57 | "min": 1,
58 | "max": -1
59 | },
60 | {
61 | "type": "TripleConstraint",
62 | "predicate": "http://www.wikidata.org/prop/direct/P195",
63 | "min": 1,
64 | "max": -1
65 | },
66 | {
67 | "type": "TripleConstraint",
68 | "predicate": "http://www.wikidata.org/prop/direct/P170",
69 | "valueExpr": "https://rawgit.com/shexSpec/shex.js/master/packages/shex-webapp/doc/creator",
70 | "min": 1,
71 | "max": -1
72 | }
73 | ]
74 | }
75 | }
76 | ],
77 | "@context": "http://www.w3.org/ns/shex.jsonld"
78 | }
79 |
--------------------------------------------------------------------------------
/prototypes/wikidata_painting/E130.shexj_generated:
--------------------------------------------------------------------------------
1 | {
2 | "type": "Schema",
3 | "start": "https://rawgit.com/shexSpec/shex.js/master/packages/shex-webapp/doc/painting",
4 | "shapes": [
5 | {
6 | "type": "Shape",
7 | "id": "https://rawgit.com/shexSpec/shex.js/master/packages/shex-webapp/doc/creator",
8 | "expression": {
9 | "type": "TripleConstraint",
10 | "predicate": "http://www.wikidata.org/prop/direct/P31",
11 | "valueExpr": {
12 | "type": "NodeConstraint",
13 | "values": [
14 | {
15 | "type": "IriStem",
16 | "stem": "http://www.wikidata.org/entity/"
17 | }
18 | ]
19 | }
20 | }
21 | },
22 | {
23 | "type": "Shape",
24 | "id": "https://rawgit.com/shexSpec/shex.js/master/packages/shex-webapp/doc/painting",
25 | "expression": {
26 | "type": "EachOf",
27 | "expressions": [
28 | {
29 | "type": "TripleConstraint",
30 | "predicate": "http://www.wikidata.org/prop/direct/P31",
31 | "valueExpr": {
32 | "type": "NodeConstraint",
33 | "values": [
34 | "http://www.wikidata.org/entity/Q3305213"
35 | ]
36 | }
37 | },
38 | {
39 | "type": "TripleConstraint",
40 | "predicate": "http://www.wikidata.org/prop/direct/P571",
41 | "valueExpr": {
42 | "type": "NodeConstraint",
43 | "datatype": "http://www.w3.org/2001/XMLSchema#dateTime"
44 | },
45 | "min": 0,
46 | "max": 1
47 | },
48 | {
49 | "type": "TripleConstraint",
50 | "predicate": "http://www.wikidata.org/prop/direct/P276",
51 | "min": 1,
52 | "max": -1
53 | },
54 | {
55 | "type": "TripleConstraint",
56 | "predicate": "http://www.wikidata.org/prop/direct/P1476",
57 | "min": 1,
58 | "max": -1
59 | },
60 | {
61 | "type": "TripleConstraint",
62 | "predicate": "http://www.wikidata.org/prop/direct/P195",
63 | "min": 1,
64 | "max": -1
65 | },
66 | {
67 | "type": "TripleConstraint",
68 | "predicate": "http://www.wikidata.org/prop/direct/P170",
69 | "valueExpr": "https://rawgit.com/shexSpec/shex.js/master/packages/shex-webapp/doc/creator",
70 | "min": 1,
71 | "max": -1
72 | }
73 | ]
74 | }
75 | }
76 | ],
77 | "@context": "http://www.w3.org/ns/shex.jsonld"
78 | }
79 |
--------------------------------------------------------------------------------
/prototypes/wikidata_painting/E130b.csv:
--------------------------------------------------------------------------------
1 | Entity_name,Property,Property_label,Mand,Repeat,Value,Value_type,Annotation
2 | painting,wdt:P31,Is a,yes,no,wd:Q3305213,URI,"Instance of ""painting"""
3 | ,wdt:P571,Date of inception,no,no,,DateTime,
4 | ,wdt:P276,Location,yes,yes,,,
5 | ,wdt:P1476,Title,yes,yes,,,
6 | ,wdt:P195,Collection,yes,yes,,,
7 | ,wdt:P170,Creator,yes,yes,creator,Entity_name,
8 | creator,wdt:P31,Is a,yes,no,wd:,URIStem,
9 |
--------------------------------------------------------------------------------
/prototypes/wikidata_painting/readme.md:
--------------------------------------------------------------------------------
1 | This prototype has two variants:
2 |
3 | * `E130.csv`, a simple [csv template](E130.csv) that is quite close to [the one discussed at the DCMI 2019 hackathon](https://github.com/dcmi/dcap/tree/master/prototypes/simpleFromHackathon)
4 |
5 | * Entity_name
6 | * Entity_label
7 | * Property
8 | * Property_label
9 | * Cardinality
10 | * Value (_not_ part of the hackathon model)
11 | * Value_type
12 | * Annotation
13 |
14 | * `E130b.csv`, a [slightly different csv template](E130b.csv) with the following:
15 |
16 | * Entity_name (but no Entity_label)
17 | * Property
18 | * Property_label
19 | * Mand (Mand and Repeat instead of one column for Cardinality)
20 | * Repeat
21 | * Value (_not_ part of the hackathon model)
22 | * Value_type
23 | * Annotation
24 |
25 | For each of these models, there is a Jupyter notebook with code that converts the profile to a Wikidata Entity Schema in ShEx:
26 |
27 | * [for converting E130.csv](E130.ipynb)
28 | * [for converting E130b.csv](E130b.ipynb)
29 |
--------------------------------------------------------------------------------
/requirements.md:
--------------------------------------------------------------------------------
1 | # Requirements and motivation for a DC-AP
2 |
3 | *(this file copied from https://github.com/kcoyle/RDF-AP/blob/master/requirements.md)*
4 |
5 | Why? Who? What? How? Why do we want to create profiles? Who needs them? What functions do they need to provide? How will they work?
6 |
7 | ## Why?
8 |
9 | Help someone else understand your data well enough to make use of it. This is not unlike the more general problem with open source: you can declare your code ‘open’ and wish people ‘good luck’ or you can provide support.
10 |
11 | * To understand variations
12 | * on a standard
13 | * among partners
14 | * within a community
15 | * along a workflow
16 | * To build consensus
17 | * by making decisions visible
18 | * by providing a focus for process
19 | * To drive applications
20 | * that validate different data representations
21 | * create Schemas for XML (XSD, RelaxNG), JSON (JSON Schema), RDF (SHACL, ShEx)
22 | * To drive user interfaces
23 | * input forms
24 | * displays
25 | * To provide a framework for developing metadata templates
26 |
27 | ## Who?
28 | * Creators: anyone providing data
29 | * Users
30 | * anyone who can/is allowed to access the data
31 | * both people AND machines - not an either/or, but should be both (? if not both, then people?)
32 |
33 | ## What?
34 | * To describe the basic structure of the data
35 | * To characterize the story that the data is designed to tell
36 | * To characterize the things described, and how they are described
37 | * To enumerate the elements that "anchor" a dataset? (E.g., the unique keys of a dbms: what has to be there to make the data useful)
38 | * To describe the content of the data in more detail
39 | * subjects - properties - objects
40 | * things - attributes - values
41 | * To describe the things that the metadata is "about"
42 | * How are those things defined?
43 | * How are they described?
44 | * How are the things related among themselves
45 | * What things can stand alone (i.e., be described independently of related things)?
46 | * Properties, attributes, elements (use the one that makes most sense to you, assume they are the same)
47 | * What properties define the things? are required?
48 | * What are the relationships between properties?
49 | * Objects, values (same)
50 | * What is the value type or types for each property
51 | * what are/is the range of/ valid values
52 | * can values change? How?
53 | * To describe relationships between values (e.g. start date <= end date)
54 |
55 | ## Administration of the profile
56 | * Versioning
57 | * Creator
58 | * Rights
59 | ## How?
60 | * markdown -> html
61 | * wiki
62 | * html with schema.org
63 |
--------------------------------------------------------------------------------
/schemaList.csv:
--------------------------------------------------------------------------------
1 | Entity,label,cardinality,property?,value?,Notes
2 | descriptionSet,,"0,1",dsp:descriptionSet,,
3 | ,descSetID,"1,1",,xsd:literal,
4 | ,display name,"1,-1",rdfs:label,xsd:literal,one value per language
5 | ,descriptions,"0,-1",dsp:description,xsd:literal (array),
6 | description,,"0,-1",dsp:description,,
7 | ,descID,"1,1",dct:identifier,xsd:literal,
8 | ,display name,"1,-1",rdfs:label,xsd:literal,one value per language?
9 | ,description,"0,1",dct:description,xsd:literal,
10 | ,example,"0,-1",vann:example,xsd:literal,
11 | ,usage note,"0,1",vann:usageNote,xsd:literal,
12 | ,class,"0,-1",rdf:type,rdfs:Class,The valid RDF class(es) for this description; only for RDF data
13 | ,min. occurrence,"0,1",sx:min,xsd:integer,Default 0
14 | ,max. occurrence,"0,1",sx:max,xsd:integer,Default -1
15 | ,statements,"0,-1",dsp:statement,xsd:literal (array),
16 | statement,,"0,-1",dsp:statement,,
17 | ,statementID,"1,1",dct:identifier,xsd:literal,
18 | ,property name,"1,1",?,xsd:literal or URI,Expected to be a URI but minimally can just be the name of a metadata element recognized by a community
19 | ,display name,"0,-1",rdfs:label,xsd:literal,one value per language
20 | ,description,"0,-1",dct:description,xsd:literal,
21 | ,usage note,"0,-1",vann:usageNote,xsd:literal,
22 | ,min. occurrence,"0,1",sx:minInclusive,xsd:integer,Default 0
23 | ,max. occurrence,"0,1",sx:maxInclusive,xsd:integer,Default -1
24 | ,value link,"0,1",sx:valueExpr,xsd:literal,Assuming a statement can be reused within a set
25 | value,,*,dsp:value (?),,* requires a statement; 1-1 with statement
26 | ,valueID,"1,1",dct:identifier,xsd:literal,
27 | ,display name,"0,-1",rdfs:label,literal or language literal,one value per language
28 | ,short description,"0,-1",dct:description,xsd:literal,
29 | ,usage note,"0,-1",vann:usageNote,xsd:literal,
30 | ,example,"0,-1",vann:example,,
31 | ,data type ,"1,1",sx:datatype,any xsd datatype,
32 | ,datatype value constraint,"0,1",sx:pattern,Grep-like string,"this needs to be a shex statement, e.g. <= today's date, or a regex?"
33 | ,max length,"0,1",sx:maxLength,,default unlimited
34 | ,min length,"0,1",sx:minLength,,Default (?)
35 | ,language tag constraint,"0,1",,,one or more language tags that are considered valid
36 | ,unique language constraint,"0,1",,ShEx issue #47 - may be available in the future,only one occurrence of each language tag is allowed
37 | ,literal value list,"0,1",,xsd:literal,"Eg:red, blue, green"
38 | ,,,,,
39 | ,,,,,
40 | namespaces,http://vocab.org/vann/,vann,,,
41 | ,http://purl.org/dc/terms/,dct,,,
42 | ,http://www.w3.org/ns/dcat,dcat,,,
43 | ,http://www.w3.org/2001/XMLSchema,xsd,,,
44 | ,http://www.w3.org/ns/shex,sx,,,
45 | ,http://www.w3.org/1999/02/22-rdf-syntax-ns#,rdf,,,
46 | ,http://www.w3.org/2000/01/rdf-schema#,rdfs,,,
47 | ,http://example.com/dsp,dsp,,,
48 |
--------------------------------------------------------------------------------
/shex_lite/README.md:
--------------------------------------------------------------------------------
1 | #ShExJ-Lite
2 |
3 | A subset of ShExJ which should work in any ShEx implementation.
4 |
5 | Resources:
6 | * [micro-spec](https://dcmi.github.io/dcap/shex_lite/micro-spec.html)
7 |
8 |
--------------------------------------------------------------------------------
/simpleSchema.csv:
--------------------------------------------------------------------------------
1 | Entity,label,cardinality
2 | descriptionSet,,"0,1"
3 | ,descSetID,"1,1"
4 | ,displayName,"0,-1"
5 | ,descriptions,"0,-1"
6 | description,,"0,-1"
7 | ,descID,"1,1"
8 | ,displayName,"0,-1"
9 | ,description,"0,1"
10 | ,example,"0,-1"
11 | ,usageNote,"0,1"
12 | ,class,"0,-1"
13 | ,minOccur,"0,1"
14 | ,maxOccur,"0,1"
15 | ,statements,"0,-1"
16 | statement,,"0,-1"
17 | ,statementID,"1,1"
18 | ,displayName,"0,-1"
19 | ,description,"0,-1"
20 | ,usageNote,"0,-1"
21 | ,minOccur,"0,1"
22 | ,maxOccur,"0,1"
23 | ,valueLink,"0,1"
24 | value,,"1,1"
25 | ,valueID,"1,1"
26 | ,displayName,"0,-1"
27 | ,description,"0,-1"
28 | ,usageNote,"0,-1"
29 | ,example,"0,-1"
30 | ,dataType ,"1,1"
31 | ,datatypeValueConstraint,"0,1"
32 | ,maxLength,"0,1"
33 | ,minLength,"0,1"
34 | ,languageTagConstraint,"0,1"
35 | ,uniqueLanguageConstraint,"0,1"
36 | ,literalValueList,"0,1"
37 |
--------------------------------------------------------------------------------
/template_tom/dcap_template.csv:
--------------------------------------------------------------------------------
1 | Entity Description Template,,Statement Template,,,,,,,,,,
2 | Entity-ID,Entity Label,Property Constraints,,Value Constraints,,,,,,,Cardinality,
3 | ,,Property Label,Prefixed Property URI,Value Kind,Value Entity-Ref,Value URI,Value String,Value List,String Language,String Datatype,Min,Max
4 | book,Book,Creator,dcterms:creator,bnode,creator,,,,,,1,1
5 | creator,Creator,Name,foaf:name,literal,,,,,,,1,-1
6 | ,,Homepage,foaf:homepage,uri,,,,,,,0,1
7 |
--------------------------------------------------------------------------------
/template_tom/dcap_template.xlsx:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/dcmi/dcap/a3a3f0dcda84179e9624df3a75b9277bd8d00cb7/template_tom/dcap_template.xlsx
--------------------------------------------------------------------------------
/template_tom/dcap_template2.xlsx:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/dcmi/dcap/a3a3f0dcda84179e9624df3a75b9277bd8d00cb7/template_tom/dcap_template2.xlsx
--------------------------------------------------------------------------------
/template_tom/dcap_template_20190923.xlsx:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/dcmi/dcap/a3a3f0dcda84179e9624df3a75b9277bd8d00cb7/template_tom/dcap_template_20190923.xlsx
--------------------------------------------------------------------------------
/template_tom/dcap_template_simplest.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/dcmi/dcap/a3a3f0dcda84179e9624df3a75b9277bd8d00cb7/template_tom/dcap_template_simplest.pdf
--------------------------------------------------------------------------------
/template_tom/dcap_template_simplest.xlsx:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/dcmi/dcap/a3a3f0dcda84179e9624df3a75b9277bd8d00cb7/template_tom/dcap_template_simplest.xlsx
--------------------------------------------------------------------------------
/template_tom/dcap_template_simplified.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/dcmi/dcap/a3a3f0dcda84179e9624df3a75b9277bd8d00cb7/template_tom/dcap_template_simplified.pdf
--------------------------------------------------------------------------------
/template_tom/dcap_template_simplified.xlsx:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/dcmi/dcap/a3a3f0dcda84179e9624df3a75b9277bd8d00cb7/template_tom/dcap_template_simplified.xlsx
--------------------------------------------------------------------------------
/usecase.txt:
--------------------------------------------------------------------------------
1 | Template for the creation of use cases.
2 |
3 | Create the issue with title USE CASE: (use case name)
4 | Add label: Use case
5 |
6 | ----
7 |
8 | Creator: (your name)
9 |
10 | ## Problem statement
11 | ''Description of the problem you wish to solve.''
12 |
13 | ## Stakeholders
14 | ''List of stakeholders experiencing the problem. When describing the stakeholder, please be as specific as possible (e.g., data consumer, data producer, data publisher, program, etc.) and avoid using the term user.''
15 |
16 | ## Links
17 | ''Optional link list to documents and projects this use case refers to''
18 |
19 | ## Requirements
20 | ''Mandatory requirements suggested by this use case''
21 |
22 | * Imperative sentence starting with a verb each describing an individual task in order to solve the stated problem
23 |
24 | ## Comments
25 | ''Optional section for editorial comments, suggestion and their interactive resolution''
26 |
--------------------------------------------------------------------------------