Closed kcoyle closed 3 years ago
@philbarker
we haven't yet begun to talk about how term lists get added in as value spaces
Value type = "list of literals"?
@kcoyle
I'm coming more and more to the conclusion that we cannot develop a model that works for RDF and for non-RDF data.
We are surely not the only ones, over the years, to have tried to go up one level of abstraction and define a model that encompasses a diversity of models (graphs vs trees, in different syntaxes). If you are hinting that we should focus on getting this CSV model to work with RDF data, then I very much agree. If people can use that model to validate non-RDF data too, all the better. But I do not think we should aim too high.
Because we seem to get stuck every time we try to generalize the model, I do think we should decide to develop an RDF-specific model, back it up with a variety of example profiles, each with some instance data that we can validate with ShEx. Once that is solid, we can go back and see if the same template can work with other data types, like XML, JSON, etc. I'll suggest this to the group in an email.
we haven't yet begun to talk about how term lists get added in as value spaces
Value type = "list of literals"?
I was thinking more of concept schemes, e.g. use a value from this SKOS vocabulary
@philbarker In situations I'm aware of, SKOS vocabs can be covered with a URI stem (or a set of URI stems). But there is one situation, Europeana, which allows any value that is a SKOS concept, because the list of vocabs cannot be known a priori. So it seems that SKOS concept in that case becomes itself a value type.
@kcoyle This was a great discussion (and I have labeled it as such), but I think we have resolved the basic terminological issues. Perhaps close?
Decision made to use "shape" and "shapeID"
The application profile is generally defined as metadata for a description of one or more things. The DCAM and DSP defined the structure of the profile as:
"Entity" is what we are currently calling the "description" level in our simple template. The entity is represented in a column called "entity_name" which is an identifier for the entity; it could be a simple literal name, or it could be an IRI. There is an "entity_label" column for human display.