search

rdawg-pidinst / schema

RDA WG PIDINST Metadata Schema
Other
20 stars 4 forks source link

Model Identifier #38

Closed markusstocker closed 4 years ago

markusstocker commented 4 years ago

We have discussed linking instrument instances to model descriptions, via identifiers. Currently, the schema only includes a model name. To enable link to models, one proposal is to model 'Model' as we currently do with 'Manufacturer', i.e. in addition to 'modelName' include 'modelIdentifier' and 'modelIdentifierType' (RRID may be a type example).

louatbodc commented 4 years ago

Agreed. This is similar to issue

RKrahl commented 4 years ago

Two minor issues with that:

  1. At the moment, modelName is a subproperty of Manufacturer. I guess, the idea was that model names are mostly relevant for commercial built instruments and then it is the manufacturer who defines that name. If we now add subproperties to that, well, technically it might be possible to have subsubproperties and subsubsubproperties, but I guess that gets awkward. It might be better to promote Model to a main property on its own right and to add modelName and modelIdentifier as subproperties of that.

  2. In the mapping onto DataCite, we don't even have modelName, because there is no suitable property in the DataCite schema. There is the request to add a Series property at DataCite for this reason, see Issue datacite/datacite#1674. So we might want to amend that issue with DataCite as well accordingly.

markusstocker commented 4 years ago

I was about to ask what are the pros/cons of having Model encapsulated in Manufacturer or on its own right. I guess the hierarchy may be awkward but are there any advantages in modelling it as part of Manufacturer?

On your point 2: Wouldn't it still make sense to include Series in DataCite, and Model/modelName to Series? I think the point we make in the datacite/datacite#1674 (that model is important for instruments) is still valid.

RKrahl commented 4 years ago

Actually, I don't see any advantage of having modelName a subproperty of Manufacturer. Putting it there was done mostly intuitively, like “it's attributed by the manufacturer, so let's put it below the Manufacturer property”, rather then a well thought-out design.

It has however an interesting disadvantage that I only noticed now that we discuss modelIdentifier: an instrument should only have one single model name. Consequently modelName has cardinality 0-1. But Manufacturer has cardinality 1-n, because more then one person or institution may be involved in creating the instrument. Now if you have like three manufacturers, you will implicitly have up to three model names, because you may put one in each of the Manufacturer entries. Or, if you have only one model name, you are forced to decide, which one of the manufacturers you attach that name to. That is weird. The same for consumers of the metadata, they have to look for the model name in each of the Manufacturer entries and they have to decide what to do if they find more then one model name. That design is not very consistent.

RKrahl commented 4 years ago

Concerning the Series in DataCite: that property name has been proposed as a generalization of modelName. DataCite is not only for instruments, but first of all for data and then for lots of different things. So the DataCite schema needs to fit for all of that. A model name probably only makes sense for instruments, so a modelName property would not fit well in the DataCite schema. But many things come in series: books, conferences, papers. Even datasets: consider some environmental data that is measured in the same way in regular intervals. So a Series property would make sense for DataCite in general. And it would also fit for instruments to accommodate the model name, because an instrument model is just that, a well defined series of individual instruments.

And thus, no, it would not make sense to add modelName to Series in DataCite.

My suggestion to amend the proposal for a Series property in DataCite would be to make that a complex property in the same way as we do for Model here: a Series property with subproperties seriesName, seriesIdentifier, and seriesIdentifierType.