Dividing responsibilities between Datatypes and Properties

[joepio]

In the Atomic-Data-Browser app, I use Classes, Properties and Datatypes to render the form and validate its inputs. The Class dictates which required and optional properties are used, the properties determine the labels, and the datatypes determine the type of form input. A normal string is a simple single line input, a markdown field a multiline one (perhaps with some UI elements for markdown syntax), a ResourceArray a more complex field with ordering, and so forth. And then, there is possibly some validation. A Slug, for example, checks if a string consists of only dashes, numbers and letters.

The problem is, I feel like sometimes the property should do validation, and not the datatype. If only datatypes do validation, we might get a lot of datatypes. I'm not sure if that is a bad thing, but it might be.

Approaches

I think we have (at least) two options:

Only datatypes do validation (status quo)

• Strict distinction between semantics and data
• Results in lots of datatypes
• Many properties can use the same datatype
• Might result in datatypes that are only used by a single property, which means that the user has to create both a property and a datatype.
• We might need to add a regex field

Only Properties can do dynamic validations

• Users cannot / should rarely create a new datatype
• Properties have an optional regex field
• Harder to re-use validation by other properties, which means we might get a lot of similar, yet different, validations.

Both can do dynamic validations

• Every time a user wants to model something, they have to make this decision. Making decisions is not fun.
• Enables re-use when it makes sense (user puts validation on datatype)

Examples

Let's consider some (not yet existing) properties that might require validation. Think about the form field, the validation, and whether the datatype could be re-usable in various contexts.

Phone number

An international phone number, such as +31123456789. Seems only relevant in a 'phonenumber' property.

Public key

A 32 bit base-64 serialized ed25519 public key. Don't think this is usable in any other property. Key can be validated with some JS - regex won't suffice.

Color

A hexadecimal color value, e.g.EEFF22. Could be usable in many semantic contexts, such as 'backgroundColor' and 'buttonCollor'. Should offer a colorpicker, probably.

Very large numbers

When describing concepts in physics, large numbers like10^36 are pretty common. These could break normal u64 ints, so they cannot be integers. We can come across these in many properties, such as length in meters or count of a molar mass.

Current conclusions:

• If it will require a different input type / form fiel, and can be shared across various properties, it probably is a new Datatype.

[hoijui]

I am also not sure, but I would probably go for the datatype-only approach. I feel that in triples based data, especially if there are no blank-nodes, there will anyway be lots of resources that ... in our human way of looking at it, should not be independent "bubbles in the graph". to prevent that for data-types in this way, would not improve this dramatically, and I think the solution has to be different.. either we have to "switch" the idea in our head of what looks right, or we filter the graph before rendering. but also this is just a first hunch of mine, and it should be tested in practice.