valueNodeType

[kcoyle]

Another aspect of DCTAP that was confusing to tutorial attendees was the valueNodeType. The confusion seems to have come from the use of a separate column for this since it could be seen as just another valueType. Phil and I couldn't remember the need for this vis-a-vis having a single column for the object of the triple.

If the rationale is that you need to say both "literal node" and give a literal type, it seems that could be inferred from the definition of a literal in the valueType column. So that column could have:

valueType	inferred node
IRI	IRI
BNODE	BNODE
IRI or BNODE	IRI or BNODE
xsd:etc	literal node
anything else here	literal node

Those not focused on RDF can still use IRI/URI/URL even if in their schema language that will be a string value. Those needing to identify specific node types can do so in whatever program interprets the DCTAP.

[kcoyle]

valueType	inferred node
IRI	IRI
BNODE	BNODE
IRI or BNODE	IRI or BNODE
"thing"	NODE
xsd:etc	literal node
anything else here	literal node

There is also the "value" that is a link to a shape. The statement template takes a different form in that case, so we could deal with that by describing two kinds of statement templates:

1. Simple/single value
2. Complex value
   This could be useful for folks using XML who think in terms of simple and complex structures.

[philbarker]

I think part of the difficulty was that the terms used are very RDF specific while the concept of there being either a simple/single value or a set of values is quite common. I think it's to some extent related to the difference between a value for a characteristic of the thing being described or a link to a description of some related thing.

I have been trying think about how it comes up in different modelling paradigms:

Paradigm	Simple values	Complex values	Comments
Graph / RDF	Literal node	IRI or BNode	IRI if you want the description to be available beyond the graph
RDBMS	data in cell	foreign key for related table
Tree / XML	simple type or attribute	complex type
Tree / JSON	string, number or boolean	object	Arrays are repeated nodes or either type
Tree (abstract)	leaf nodes	includes a pointer to child nodes

I don't know enough about Property Graphs to put them in, I suspect that for them and RDF-star we would need something not in the current TAP to describe data about edges (which might be where some uses of XML's attributes fit as well).

Does this help at all?

[tombaker]

@philbarker @kcoyle these are great questions.

I continue to feel that we should not try to define a set of columns that will work equally well across relational, tree, and graph models because I continue to believe that the goal is not realistic, though many have tried.

Rather, we should accept that there are different modeling paradigms and say clearly that a given DCTAP may not necessarily work across paradigms: that DCTAP is not a universal (or exchange) format for application profiles in general but a basis for creating flavors of the DCTAP model that are customized for specific purposes.

For example, a DCTAP flavor could serve as a simplified syntax for ShEx, and it might extend the base model with a column for indicating the starting point for graph traversal (keyword "START") and a column in a given Shape template for pointing to another Shape that the given shape "EXTENDS".

AFAICT the notion of an RDF "structured value", with its label-like "default value", rdf:value, arose in the late 1990s precisely because, as shown nicely above, the concept of there being "either a simple/single value or a set of values is [and back then already was] quite common". While I recognized that the RDF notion of "structured value" could help anyone approaching RDF with, say, an XML mindset, I never thought it was a particularly helpful notion for anyone approaching RDF already with a graph mindset.

Basically, I'm all for writing up explanations that help people make good use of DCTAP within their modeling paradigm of choice. However, I would feel uneasy if we were to try to define a model that works with all paradigms. If there are elements of the basic DCTAP model, such as valueNodeType, that people not working with RDF find confusing, I would rather keep valueNodeType for use in an RDF- (or ShEx-) specific flavor of DCTAP than try to replace it with something that tries to be more universal.

[philbarker]

Thanks @tombaker, I think we are (mostly) in a agreement. This is about writing up explanations that help people understand DCTAP as it is, and not about trying to create a version of TAP that works for all paradigms; I never much liked "structured values" in RDF either.
Perhaps our only point of disagreement will be around how to help people, because I think the problem is that there are many people who are not working [directly] with RDF and don't much understand it who will be integral to encouraging adoption of DCTAP. I include in these the domain experts whose input is necessary and developers who never get much past the first four letters of JSON-LD. If we assume that the audience for DCTAP is the ShEx and SHACL users then I think they will probably just use ShEx or SHACL, or maybe one of the more technically oriented approaches to generating those (like LinkML). I think we need at least a view on the RDF ShEx or SHACL focussed TAP that makes sense to them. I hope this can be addressed in user interfaces and hiding terms like Literal/IRI/BNode behind aliases.

[tombaker]

Thank you @philbarker . I continue to view DCTAP as a pragmatic, semi-formal way to document application profile structures - as a template that can help people organize and communicate their thoughts. The explanation of DCTAP can provide an opportunity for some nice teaching moments.

If we assume that the audience for DCTAP is the ShEx and SHACL users then I think they will probably just use ShEx or SHACL

Yes, agreed, though I think DCTAP can provide a simpler, more approachable interface to heavier languages like ShEx (which is how we use it in a project).

I think we need at least a view on the RDF ShEx or SHACL focussed TAP that makes sense to them.

Yes, agreed.

Perhaps our only point of disagreement will be around how to help people,

If you are suggesting that the explanation for DCTAP be made more approachable for people who do not think in terms of RDF, I have no problem with that, on the contrary - as long as we also provide that "view on the RDF ShEx or SHACL focussed TAP".

[kcoyle]

The question remains: for those who do not need to define the valueNodeType, or who don't understand it, can we show examples where IRI is in the valueType column? There are many uses of IRIs outside of RDF, and we haven't so far provided for those in our documentation.

(Note: We could also allow BNODE but that's a level of understanding of the code that may not exist at the DCTAP level. Also, as I say somewhere above, the valueShape links will be BNODEs in many cases, but we aren't giving a valueType for those since it's implicit.)

[philbarker]

@kcoyle I think it depends on what we're trying to do with the AP in question.

If it is wholly outside of RDF or if what is required is a URI that is not treated as an RDF node identifier, then the data type xsd:anyURI is there to use.

OTOH, we need to be a bit more careful in providing examples for RDF profiles that illustrate what people who don't understand NodeTypes might do! I do understand what you mean, but I think such use cases need to be addressed at the user interface level. Maybe there is scope to do something in the Cookbook? Something like "How to hide the conceptually arcane stuff".

[kcoyle]

So far we haven't shown any examples with xsd:anyURI, so maybe that's the place to start. I suspect that for many people a valueType of "character", "number", "URI" will be in their vocabulary, and of course there is nothing to prevent them from doing that. Perhaps the cookbook should have examples of RDF TAPs and non-RDF TAPs.

[kcoyle]

Another thought: will there be folks who use OWL who will want to designate the OWL property type in a TAP? The annotationProperty, which takes any type of value, may be particularly useful for some. And the object Property, if I am not mistaken, is essentially IRI or BNODE. If you are creating a profile of a vocabulary already defined in OWL, maybe this is what makes sense. Of course that doesn't translate directly into SHACL or ShEx if you have more strict constraints. But maybe the cookbook could have an example? And if so, would using the valueNodeType be ok?

[philbarker]

I think you're right about OWL Object Properties. There are also "so-called Datatype properties. These properties relate individuals to data values (instead of to other individuals), and many of the XML Schema datatypes can be used" (OWL Primer §4.8).
Not so sure about annotation properties being useful, as these are used to define/describe the ontology rather than used in metadata instances.
I think defining the property type belongs in the standard on which the profile is based, but yes, it has implications for what elements of a statement template are relevant.

[tombaker]

Would it work simply to say: "valueNodeType is only really useful if you are creating a profile for RDF data"? In other words, simply de-emphasize the element as something that is useful only if applicable?

can we show examples where IRI is in the valueType column? There are many uses of IRIs outside of RDF, and we haven't so far provided for those in our documentation.

I agree with this but wonder if we would really need to refer to it as an IRI. That is of course the correct term for "URI", but in my experience, there are plenty of people, even IT-savvy people, who do not know what a URI is. But just about everyone knows what a URL is. I googled for examples of xsd:anyURI and almost all were for websites or APIs and none were about URIs used specifically as identifiers.

[kcoyle]

@tombaker I do like the idea of wording it like that - maybe this also is a cookbook entry, showing the function of the valueNodeType for ShEx and SHACL - because if I'm not wrong that is the main usage.

I also agree that we should use the term "URI" as it is the more common term.

I'll see how I can work these into the documentation and cookbook. I'll undoubtedly need help for the latter because I don't really know how they are used in validation.