Time: 14:00 UTC (check time) Zoom Join URL: https://us02web.zoom.us/j/89385510030?pwd=bnI5RWNlNkROUm9zNUZObHBZenBzQT09 HackMD agenda: https://hackmd.io/ISXarfxZTv-BcX_4BGxqUA
Minutes of previous meeting
- Tom
- Karen
- Phil
- John
- Nishad
- Review "tutorial" documentation
- Definition of "shape" (github discussion)
- Review diagrams
- Review appendices
- Plan for full example and other examples?
- Review vocabulary document
- Sample profiles and instance data for December event
Nov 4
discussion on shape and statement #73
tom suggests 'constraint statement' - because we run up against using terms that also describe the instance data. We need a definition that gives an idea of what is in a statement. Suggest: "property and value constraints".
phil: clear if we say that statement is something in the metadata, so better to say "statement constraint" so there's no confusion between profile and metadata. Suggests: statement constraint: a group of property and value constraints on how a statement may be made in metadata
tom and karen want to go with "something"
tom: "a group of property and value constraints on metadata statements" - then we define "metadata statements"
kc: not good to use statement in term and definition. Prefer use of "something in metadata"
phil: problem is that a shape also describes something in metadata -
kc: need to define metadata statements. don't have a definition of statement in the DSP that we can lean on
dcam: Each statement instantiates a property-value pair, and is made up of a property URI (a URI that identifies a property) and a value surrogate
Phil: statements are in instance data, and AP is statement constraints. Need to differentiate between instance data and profile. Start with instance data (which folks supposedly understand) and then say what profile is in relation to instance data
kc: describing instance data will be tricky
tom: property value pair that describes a resource; need to say enough about instance data to make profile clear
(looking at vocabulary document) https://hackmd.io/ZO2YqSJERjyALrfRtNjzjQ
kc: could define metadata in intro, not in definition list
tom: in rdf it is conceptually a graph
phil: include entity and statement in profile vocabulary
tom: two sections - one that provides a glossary of terms that includes instance data.
kc: need definition of metadata
tom: metadata is comprised of statements; statement is a triple or property/value pair describing a particular resource; see rdf primer
kc: statements are in instance data, shapes are in profile
tom: profile is a constraint on statements
kc: in profile, shape is group of constraints on statements
tom: need a glossary in the primer; statement is something in the rdf model in stance data; we don't need to include statement in our tabular model
jh: i like the idea of separating statements and constraints on statements; shape as a group of statements is missing something - doesn't say what the organizing principle is that makes statements into a group
kc: (points to github issue) "a group of property and value constraints on how something may be described in metadata"
tom: constraints on statements
kc: needs more meaning;
phil: a group of statement constraints that describe a type of thing in metadata
jh: there are shapes in the metadata; what are we calling that, if not shape?
tom: shape is just profile, a view over the metadata
kc: 'view over' assumes data already exists; doesn't help you create data; shex is also a post data creation
kc: we can refer to graphs in instance data, but try to not be too rdf-centric 'in rdf this is called a graph'
kc: need an introduction to one or both documents: purpose of profile is to constrain metadata, then something about constraining property/value pair statements, and then groups of statements that form graphs or shapes
tom: like "how something may be described in metadata"
ACTION: kc will write this up as intro to both documents;
Topic: tutorial document
kc: shows that csv was removed; but added appendices with an example with csv. Then list of unresolved issues.
Phil: need a list of out of scope; like complex combinations of and/or/not, co-dependencies (don't belong in a simple tabular format)
tom: an outcome could be a paper that looks at more full-featured solutions like shex/shacl, etc.
Phil: touch on some of this in the primer
kc: where in the primer? An appendix, and refer to it in the introduction. "Known limitations of the model"
kc: need to replace diagram with phil's example. Need to explain that although we have defered value constraint and value constraint type, this is the only way to show class membership. Need a note to say that this is provisional
tom: to me the only part we haven't fleshed out is value constraint type
(long discussion about this)
phil: have other possible constraints in the notes
tom: if the value is singular then don't need value constraint
Phil: this the value that it must be
(gets into question of how profile usage relates to underlying vocabulary term definition - leaves validity of profile to humans? Or if validating profile, need to go back to vocabulary to determine proper usage.)
RESOLVED: Value constraint type only needed where value is not a literal to be used as is.
phil: can also have mis-matches between value node type and the property. not actually inheritance but AP is definitely tied to the vocabularies it reuses.
kc: what carries forward from the vocabulary? domain? range? labels? definitions? very complex, not ready to go into document
tom: we can define not very complex value constraint types; look at shex for list. We can probably come up with a small list; try to find a way to do common ones like min/max, pick list, uri stem