philbarker
commented
7 months ago That makes sense, and seems fine for documentation though many columns makes documentation harder on the eye. However, I wonder how it could be actioned in any automated process; for example, how would you turn it into ShEx or SHACL or another data validation approach.
You could see an Application Profile as being suggestions for what data should be provided, the question is what happens if those suggestions aren't followed. SHACL provides a "severity" property to specify whether non-adherence to a shape triggers a Violation, Warning, or Information message; there is another property for the message. So what I do for optional "suggested values" is to mark them as triggering an Information message saying that they haven't used the suggested value.
I have also seen profiles with different sets of rules for tight and loose compliance, where the loose compliance does not include the warnings and information messages. Useful for people who know about the suggested values and choose to ignore them.
So what I have done for some TAPs is to add a "severity" column, that gets mapped to the SHACL sh:severity property.
The SRAP work is bringing up the question of suggested values. They are hoping to be somewhat prescriptive but also not overly constrained. For a property that might be either a string or an IRI, and where there are a few preferred IRI stems but none that are required, there doesn't seem to be a way to express this in a TAP. Presumably a new column could be added for "preferred" values. That might actually mean two columns, one for string values and one for IRIstems. I thought of using the TAP note field, but that field can contain anything, and making it work in this case would be a kludge.
If we think this is not appropriate for the basic TAP, what can we show in a cookbook entry that would help?