# Questions from August 26 meeting re: value types

## Strict or loose?

Before deciding on an RDF-specific profile, the value types that were being defined were loose - they had no formal definitions. We were thinking of defining a small number of common types but allowing profilers to add from their own local idiom as desired. More information could be included in the Annotation column.

With RDF, the types are pre-defined in the RDF documentation, and could be considered to be *strict*.

Argument for strict: no ambiguity
Argument against strict: profilers need to have good knowledge of RDF

Argument for loose: friendly to less techie profilers
Argument against loose: cannot be validated except by someone who knows what was intended in the loose description

Argument for either: ??
Argument against either: No way to know what the profile really means; no way to know if the profile is a strict RDF profile or is not intending to be validated as RDF.

## Use XSD: as default in data type column?

Note, that we have no way (at the moment) to indicate that the profile is intended to define RDF data other than the contents of the columns.

Argument for: easier to type into cells, easier to read

Argument against: less precise; profilers may not realize they have to use an actual xsd: name; does not translate well to non-RDF profiles

Propose: use xsd: or rdf:/rdfs: wherever appropriate to eliminate ambiguity.

## Syntax or semantics?

Does the template value type define syntax, semantics, or both?

In looking at both ShEx and SHACL, they both validate both syntax and semantics in RDF value data types:



Suggested: if using RDF value types, both syntax and semantics are defined and presumed will be validated

## Separate columns for RDF node and RDF data type?

Options:

1. Separate column for node and datatype; datatype is only literal datatypes

* Advantages: node type is explicit; adheres to RDF defintions
* Disadvantages: requires profilers to use node type column for IRIs even though they may think of them as values; would node "Literal" with no type = xsd:string?; possibility of mis-match between the two columns (node: IRI; datatype: xsd:date)

2. Separate column with just: Literal, entity (could be called Object?); IRI, BNODE would be in column with literal datatypes

* Advantages: IRI would be in the same column with literal types and the node column would not be needed to specify IRI
* Disadvantages: The data type column would be a mix of nodes and data types

3. Separate column with just: Literal, entity (could be called Object?); IRI, BNODE would be in column with literal datatypes; first column would need to have a "literal or entity" option OR second column would have "IRI or xsd:string"