# Questions
From [May 6](https://hackmd.io/33dG6BttQ8q3H6YFH4G5tw)

1. Can minimalist profile be the core of a more extensive profile template? (We seem to agree that it SHOULD.)
3. Can the "simple" be used as is, or are more properties needed? (Have we decided "as is"?)
5. Will we want to define URIs for these properties? Do we prefer to use existing DC (or other) terms or AP-specific?
6. How to define namespaces within a tabular format?
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?
8. How will we handle multiple values in a single cell (e.g. a pick list of string values)?
9. Can valuetype be expanded to include pick lists, URI stems? Or do we limit to standard value types?
10. How can we include constraints for "recommended" and "mandatory if applicable"?
11. What transformations can we add to our prototypes?
12. Should we specifically develop a "ShEx-friendly" version? e.g. https://github.com/johnsamuelwrites/dcap/blob/master/ShExStatements/shexstatements.ipynb

## The current simple example has blank cells where entities are repeated. Should these be filled in?

1. Could be easier to code if all information is included on each row
1. Could be less easy for humans to read if all cells must be filled in
1. Would blank cells other than entity cells inherit from prior cells? (That doesn't seem like it because some cells will legitimately be blank, e.g. where no value constraints are included, where no annotations are included)

## Should there be a way to declare a base URI for the profile itself?

* This could be used as the prefix of entity IDs if required.
* Unclear by what mechanism this could be done. Maybe a keyword?
* https://github.com/dcmi/dcap/issues/61#issuecomment-641919126

## Should there be a special keyword for constraining the subject URI?

It may be useful to designate entities with URI stems. ([Adrian](https://github.com/dcmi/dcap/issues/61#issuecomment-640572492), [Tom](https://github.com/dcmi/dcap/issues/61#issuecomment-641053288), [Adrian](https://github.com/dcmi/dcap/issues/61#issuecomment-641104029))
Tom's response: https://github.com/dcmi/dcap/issues/61#issuecomment-641794396
This would mean adding a specific row keyword to say that the row's constraints are on the subject/entity identifier. ([Tom](https://github.com/dcmi/dcap/issues/61#issuecomment-641145621))

This probably only applies to the "starter" entity since all (most?) others will be objects of a statement, and that information can be in the row of which they are the object. (?true? exceptions?)

## How do you specify that the value must be an instance of a specific class, e.g. of SKOS Concept?

This may require an entity for that information, not a simple value in the value column. The *entity* would be of the class.

[Phil](https://github.com/dcmi/dcap/issues/61#issuecomment-641184411): the profile should be able to define classes, properties, and value encoding schemes. Encoding schemes (concept schemes, syntax encoding schemes) must have identifiers.

Easier option for profile creators?:
valueType = Class
value = skos:Concept

## Can the Value constraint cell be a regular expression?

No reason why not. Also, that's a way to handle IRI stems, as [per Adrian](https://github.com/dcmi/dcap/issues/61#issuecomment-641808348). See also the [Google doc third sheet](https://docs.google.com/spreadsheets/d/1pFLYCgHBQgEDliJKUrLYESOYHZJEfV31MeNeEVNuivo/edit#gid=1614476584).

## URI stem option

We've talked about using "URIstem" as a value type.

Another option for the URI stem would be to use a truncation symbol similar to what is used in database searches:

<pre>https://id.loc.gov/authorities/names*</pre>

* But note that the asterisk is a [valid character in URIs](https://www.ietf.org/rfc/rfc3986.txt).

## Handling of multiple value types with distinct values

*(This is probably a documentation issue. We should do a set of examples for different situations.)*

property is: dc:subject (a literal) or dct:subject (a URI)
<pre>
has subject -> Mandatory -> @subject
@subject
dc:subject - optional -> literal
dct:subject - optional -> URI</pre>

(kc: I note that creating "entities" to cover cases like this will be hard to explain. These aren't entities in the sense of "book" "author", but are shapes that are needed to perform some logic or choices. I don't expect that real beginners will be able to understand this. Should we include it in the documentation?)

This may be needed for the Sinopia case, where a value can be either a specific URI stem or a literal.

## What does "value type" mean?

This now seems to be "value datatype".

kc: The valid or expected data type of the value in the instance data for that property.

tom: The valid or expected type of the value in the instance data for that property

## What does "value constraint" mean?
kc: Additional constraints beyond the value type. This only needs to be filled in if there are such constraints. Example:

value type = literal
- is fine if any literal string is valid here. Nothing is entered in "value".

value type = literal; value constraint = "red" "blue" "green"; value constraint type = list (or pick list)
- is needed if not any literal is ok, but must be a choice of one of these specific values

Value constraints must be compatible the type given in value type.

## ValueType is URI or string

**Use case 1:** The valueType is URI
In the creation application, the user begins to type a string. If the string is found the URI is provided by the system. If not, a new URI is minted. This URI is a node identifier in the profile, and the string and perhaps other information is added to the node.

<pre>
@book
sdo:author valueType:URI @author
@author
foafname:
dob:...
</pre>

**Use case 2**: The valueType is URI OR LITERAL
In the creation application, the user begins to type a string. If no match is found, the string is used; if match is found, the system inserts the URI.

This assumes that the value here will be an end point in the node, as no additional information can be provided on the literal.

<pre>
@book
sdo:author valueType:URI LITERAL @author
@author
foafname:
dob:...
</pre>

The problem here is that LITERAL cannot link to @author node. What would the instance data be in this case? (possibly the system creates an internal URI or bnode for the literal, but the user is not aware of this. The literal is stored as the value to foafname even though the user sees it as the object of sdo:author.)

## URIs and BNODES

(See [Tom's comment](https://github.com/dcmi/dcap/issues/61#issuecomment-640514538))

If:
<pre>
valueType:URI @author</pre>

Is "@author" a URI, but not a BNODE? Do we think that profile creators will decide URI v BNODE?

Could this be valid:
<pre>
valueType:LITERAL @author</pre>

How to say that a @ reference is a BNODE?

Do you know at the time of profile creation if the node will be a URI or a BNODE? Could it be either?

Or could the valueType on rows with "@" references be blank? It is simply a reference to a node/shape and that is its definition.

## How to include ordered lists in profile?

[Adrian](https://github.com/dcmi/dcap/issues/61#issuecomment-641227091)

Is valueType|rdf:list sufficient? Do we want to include this in the simplest template?

## Could an entity be represented in the table with a URI?

*(Postpone: use case unclear. May be best resolved in conversion program. Answer is probably NO)*

* Karen: https://github.com/dcmi/dcap/issues/61#issuecomment-640082342
* Tom's response: https://github.com/dcmi/dcap/issues/61#issuecomment-640082342
* ask Nishad for an example; this seems to be about reusability of shapes between profiles

## Will we define "statements" (property + value)?

1. Currently there is nothing unifying the property/value pair, but this could be a statement even if there is no column for statement.

## Could statements have identifiers so they could be reused?
4. Argument against: it's easier to read/understand if all information is copy/pasted rather than having a reference to a statement that is defined elsewhere ([April 22](https://hackmd.io/uTJ5rvD2QHyyJn2j2-voLA))

## How should multiple values in a cell be handled?
e.g. Multiple labels in different languages would be multiple label columns with "@" language codes, or they could be multiple values in a single cell: "x@en, y@fr"

There will also be questions of multiple values in the value field (multiple IRI stems, multiple values from pick lists) ([April 22](https://hackmd.io/uTJ5rvD2QHyyJn2j2-voLA))

## **valueDataType**
examples: include "xsd:" in the examples, or can this be assumed? Do we want to strictly use xsd datatypes or should we make a default list that has more natural types, like "year"? (User doc)

## Value constraints
We haven't defined any particular **value constraints**. We did talk about a "value constraint type" (e.g. URIstem [1], regex). Could this be left open, to be internal to applications, or do we need to be more specific? (User doc)