Location of Instrument

[kitchenprinzessin3880]

Which element can be used to represent the location (geo/locality) of an instrument?

[RKrahl]

Good question! We currently do not have this in the schema, I'm afraid. Do you believe this is needed? If yes, would you mind making a proposal how it should be represented?

[markusstocker]

Location is surely interesting but difficult. How do we handle the fact that instruments relocate or are mobile? I don't think it is feasible to keep this kind of metadata up-to-date at the PID infrastructure level. I see it more on landing pages. I think it is a matter of what kind of search (or other applications) we want to build on top of PID infrastructure and if these need to search along the spatial dimension. Would surely be interesting to be able to retrieve all scientific instruments that are currently in Scandinavia but I don't think it is obvious to implement.

While space and time are complex to represent, I think the most trivial representation would be some URI representing the place (say, a GeoNames URI). For coordinates, WKT may be useful (GeoSPARQL provides a possible vocabulary).

[RKrahl]

I'd say, if we decide to adopt it, this should be an optional property in any case, as it will not be relevant for most use cases. At least for our instruments, the street address of the owner is specific enough as a location. I could imagine this property to be relevant in some cases, seismic sensors for instance, but I'm not an expert in this field.

As for all metadata, the maintainer of the PID would be responsible for the accuracy. So, for a relocatable instrument, either, if the location is important for the use case, the maintainer undertakes to timely update it whenever the instrument is moved, or the location should be left out, which is ok for an optional property.

DataCite has Geolocation with many subproperties. We could follow this model, although it might be somewhat too elaborated for instruments. In any case, I'd like to get feedback of someone who actually intends to use this before finally deciding on this.

[kitchenprinzessin3880]

Helo all.. sorry for not replying sooner (still on sick leave).. In any case, I'd like to get feedback of someone who actually intends to use this before finally deciding on this. -> +1. I am not sure who are the main users of our initiative; i missed several telecon before, so you guys might have already identified potential users..anyways, if the users are are instrument operators (e.g., csiro, tereno-fzj, awi, geoscience australia) then location is important (for management & maintenance purposes). if the users are data providers (such as pangaea), then we may no need to capture the location. currently, pangaea only storing the pids of instruments from awi. also, by capturing location, we can come up with a map-based search interface for finding the instruments from various providers (if we want to do this..), e.g.,: https://igsn2.csiro.au/portal/#/browse the portal enable users to find igsns (pid for specimens) registered by different agents in australia..

would you mind making a proposal how it should be represented?

• see the location element in https://github.com/kitchenprinzessin3880/csiro-igsn-schema/blob/master/3.0/igsn-ciro-v3.0-annotation.png this is csiro igsn schema which i developed based on datacite metadata schema to represent specimens. i simplified the location representation..

[RKrahl]

We discussed this in today's meeting:

• we believe that there are many open question with this idea, including: what properties would be needed? What about altitude? How to represent them? Based on which model? How should updates be managed?
• we definitely would need more feedback from possible adopters.
• we leave the issue open for now to allow the discussion to evolve.
• we won't add this unless somebody comes up with a suitable solution for the open issues.

[ngalbraith]

The OceanSITES project is hoping to implement this in some form; we have been struggling with instrument identification for a long time. The key word here, though, is 'persistent', and the location of an instrument, at least in our work, is anything but that.

To include locations, if needed, of an instrument that is deployed repeatedly, you could use 10. RelatedIdentifier, to point to a deployment of an instrument, and then 10.2 relationType - IsComponentOf. The dates would then presumably be available in the record pointed to by the RelatedIdentifier. I suppose for a stationary instrument, the RelatedIdentifier could point to an institution or lab.

[RKrahl]

Sounds like a valid approach. Mostly because it could cover a wide range of different scenarios and would also be able to handle the history.

Only one detail: IsComponentOf has been intended to relate to another instrument. E.g. a large instrument might have several sensors that are considered to be instruments on their own. If one wants to issue PIDINSTs for both, the composite instrument and its individual components respectively, these PIDINSTs would relate to each other as HasComponent / IsComponentOf. I'd prefer to keep these relation types reserved for this usage and rather add a new one dedicated to deployments, maybe WasUsedIn or something similar.

For instruments in a lab, I guess one would not need to indicate the location at all.

[RKrahl]

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

[RKrahl]

Close as discussed in to meeting today.