allow plural in type

[lueck]

For type properties throughout the LOD schema of the specs, plural should be allowed.

E.g., the specs require the type of a resource object returned by the collection endpoint to be of "@type": "Resource". Good! This tells us, that the object is a dts:Resource.

Now, consider, that this same object is not only a dts:Resource but also a frbr:Manifestation or a lrm:F5 in terms of FRBR or LRM. Thus, we want:

"@type": [ "Resource", "lrm:F5" ]

Allowing plural for the type is especially important after allowing nested metadata objects in #280, which was essential for providing useful RDF data through the endpoints.

[PonteIneptique]

In my view (and only mine), this addition isn’t necessary and would introduce avoidable complexity—especially for users who are not familiar with RDF.

One of the core goals of DTS is to strike a pragmatic balance: we want to remain compatible with RDF where it adds value, but also recognize that most developers—and even many digital editors—either lack experience with RDF or have little incentive to engage with it deeply.

Introducing this kind of “plasticity” into the specifications risks tipping that balance in the wrong direction. It would place an additional parsing and implementation burden on the majority of users, without a clear, proportional benefit. From that perspective, keeping the specification simpler and more predictable seems preferable.

[lueck]

#300 (this) and #301 seem to be different approaches to more plasticity. Keeping singular on type, but using an alias type would perfectly do the job as far as I see right now.

[lueck]

Generally speaking: I consider the RDF properties and classes defined in the DTS context properties for the transportation layer or channel (server-client protocol). But they are not really properties of the interesting dataset or message, because we have more sophisticated ontologies for that like FRBRoo and LRMoo, which can be used to describe a document in context of its text tradition (which DCTerms and DTS cannot), and we need that in the context of critical editions.

So, IMO, we need elasticity in order to keep the channel out of the way of the interesting dataset.

There are two approaches to keep the channel and the message apart: 1) Merge Side-by-side: Then we need plural. 2) Re-definition: Then we need the aliasing from #301.

[PonteIneptique]

@lueck Nothing would be possible at the extension level to cover your need ?

[lueck]

Same as with the with the dublincore metadata object: I'd use @nest, because it is the resource, the RDF statements are about, not some 'extension' of it. (see #280) The extension is good for keeping things clear at the JSON level. But on the data-level of RDF, statements about the resource have to be done.