dcmi / dcap

DC Tabular Application Profile - supporting materials
28 stars 12 forks source link

Multiple values in a cell #65

Closed kcoyle closed 3 years ago

kcoyle commented 4 years ago

We need a simple rule for including more than one value for a cell. This comes up with labels (where there can be more than one label because of language strings) and value constraints (pick lists, multiple URI stems, etc.) What are some possibilities here? Ideally we should select one.

philbarker commented 4 years ago

Am I right in thinking that multiple values in a single cell will always be alternatives, i.e. conbined with logical OR. I think if anyone wants both of two values (logical AND, eg. rdf:type must be schema:Book and bibo:Book) then they would repeat the row?

Language string labels presumably have the added complexity that we need language: value pairs.

kcoyle commented 4 years ago

I think we should start with OR, which seems to be the more useful case. Although I can imagine needing AND perhaps we can consider that second.

As for language strings, at the moment I was thinking only of the rdf:langString in which the string and language are presented as a single literal unit, like "title"@en "titolo"@it

2.5 rdf:langString

The class rdf:langString is the class of language-tagged string values. rdf:langString is an instance of rdfs:Datatype and a subclass of rdfs:Literal

kcoyle commented 4 years ago

@philbarker I thought again about your example. In the case of rdf:type it can clearly be repeated, just as many other properties can be repeated. The repetition is an implied AND. We do not have (yet) a way to clearly state either OR or AND between properties, e.g. (foaf:name OR (foaf:familyName AND foaf:givenName)). rdf:type may be a particular exception due to the rules regarding RDF classes, to whit that "things" can be members of more than one class. This kind of relationship between properties (or even between entities) is even harder to express in a tabular form than the "OR" that this issue addresses. I had some ideas around this but I think it fits better into a 2nd phase of our template.

kcoyle commented 3 years ago

This is now being discussed at https://github.com/dcmi/dctap/issues/4, which links backed to here.