Include model name, resource type?

[louatbodc]

These properties were as popular as landing Page URL in the use-case alignment. Should we inlcude them as optional fields in addition to owner identifier?

Also, is there a possibility of duplicating the landing page URL registered at DataCITE or PID provider?

[RKrahl]

This seem to be three unrelated issues:

1. Suggestion to add model name
2. Suggestion to add resource type
3. Duplicate of landing page URL registered at DataCITE or PID provider

My thoughts:

1. I'm fine with it. I guess it should be an optional subproperty of Manufacturer.
2. Not sure what this is supposed to be. The "resource type" would always be "Instrument" or what else would you put there?
3. The URL registered at DataCITE or PID provider is the landing page. We didn't yet decide on a technical platform for the PID infrastructure. As a result, the schema is agnostic about technical details how and where each item in the schema is to be stored. In any case, the URL registered at the PID provider is part of the metadata to be registered with the PID. This fact is reflected by having a landing page property in the schema.

[uscw]

I especially refer here to the inclusion of 'model' into the schema. Resource type and URL are already included in the schema. My suggestion would be to introduce an additional property 'model' that describes the model or series of an instrument, in free text the model or series number given by the manufacturer and optional a PID referring to the model, also given by the manufacturer. This field, so at least the model or series number, should be mandatory, because the vast mayority of instruments are made by industrial serial processes and have such a series number. All others are probably build out of industrially produced sensors, where again the model or series plays a role. And also I would suggest to change a bit the descriptions of the properties in the given metadata schema to allow manufacturers to use the same schema for models or series. This latter would probably lead to another issue here.

[huberrob]

I agree... it would be good to have some more properties which are instrument specific. I can understand the generic way how e.g. related IDs are now handled, but in some cases it would be simply more convenient to have properties such as 'model' or 'modelID'.

[RKrahl]

@uscw, could you please be specific what your proposal is: are you suggesting to add a modelName property or are you suggesting a serialNumber property? Or both? If you suggest modelName, you might want to have a look and comment on #12, I submitted this PR in response of this issue. If you suggest serialNumber, please note that there is already #5, so you might want to join this discussion.

Note that I disagree with your assertion that “the vast mayority of instruments are made by industrial serial processes”. Most instruments that I am aware of and that are candidate for an instrument PID are custom built by the owning institute and have neither a model name nor a serial number. Therefore I strongly disagree with making any of these properties mandatory, as it does not make sense to make a property mandatory that many candidate instruments simply don't have.

[RKrahl]

Note that modelName is now included after the merge of #12.

[uscw]

for identification purposes it would be better from my point of view to have an optional subfield 'seriesName' of modelName:

5.3.1 | seriesName | O | 0-1 | Name of the series inside a model as attributed by the manufacturer | Free text

[RKrahl]

Meanwhile, we have Model with sub properties modelName, modelIdentifier, and modelIdentifierType. I guess this issue has been settled. I suggest to close it.

[RKrahl]

Close as discussed in to meeting today.