search

rdawg-pidinst / schema

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

Ensure basic compatibility with TEDS / IEEE 1451.4 (plug & play sensors) #20

Closed huberrob closed 3 years ago

huberrob commented 5 years ago

IEEE 1451.4 is a industry standards for plug & play sensors and TEDS stands for Transducer Electronic Data Sheets

TEDS provides ways to identify sensors, basic TEDS includes: • Manufacturer ID • Model Number • Version Letter • Version Number • Serial Number

https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/tutorials/teds.pdf

RKrahl commented 5 years ago

Could you elaborate in more detail, why compatibility is an issue here and what you suggest to do to ensure this compatibility?

huberrob commented 5 years ago

In terms of metadata compatibility e.g. to allow semi-automatic entry of our PIDINST schema in the future by plug & play sensors

On Thu, Mar 7, 2019 at 3:50 PM Rolf Krahl notifications@github.com wrote:

Could you elaborate in more detail, why compatibility is an issue here and what you suggest to do to ensure this compatibility?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rdawg-pidinst/schema/issues/20#issuecomment-470554846, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVuxzaiAwh9zjw-JIZeq0NR0DUJ5eNNks5vUScdgaJpZM4biuPz .

-- Dr. Robert Huber,

PANGAEA - www.pangaea.de

MARUM - Center for Marine Environmental Sciences University Bremen Leobener Strasse POB 330 440 28359 Bremen Phone ++49 421 218-65593, Fax ++49 421 218-65505 e-mail rhuber@uni-bremen.de

louatbodc commented 5 years ago

Hi Rolf and Robert

I guess the marine domain is one of the further advanced use cases using sensor-machine readable technology/standards, particularly with plug 'n' play sensors. This is probably why some of us have been active in including some of the more sensor specific properties and that they are understood by machine agents. However, I also appreciate there needs to be a happy minimum that satisfies all use cases which may be why we've not been able to include all.

I think manufacturer, model and serial no. are now better described for this purpose - although I do think we need a controlled list of values for alternateidentifiertype, so a machine can understand they are looking at serial no. or an inventory number. From our use cases, we've only identified two values so far so this should be practical. Should there be a need for others, we can always add to it. Should it rapidly expand we can always revise. If we include the use of 'other' (as DataCIte do) this will also help for now.

A lot of manufacturers will include the version in the model name - is this a happy medium Robert? Or do you think we need a version property?

Cheers Lou

P.S. We could publish controlled list of values at BODC on our NERC Vocabulary Server. They will have full provenance (resolvable URIs to a machine readable description (e.g. http://vocab.nerc.ac.uk/collection/L22/current/TOOL0037/)).

RKrahl commented 3 years ago

I guess this has been settled by now. I suggest to close.

RKrahl commented 3 years ago

Close as discussed in to meeting today.