Add ID property for the PIDINST record

[ErinKenna]

I'd like to propose, for consideration, a property for an identifier for the PIDINST record itself.
Could be recommended rather than mandatory because it might come down to how people implement things.
I don't have a proposed label for this property (normally I would have used identifier for this).

I read the discussion in issue: #15. Which answers some of my questions and raises some.

I've mostly dealt with Identifiers for digital things and, for a while now, I've been conflating PIDs for real-world things vs what they dereference to and struggling to understand how people distinguish between when you are identifying the thing versus the description of the thing. For some it's well understand but some of us ( i.e. me :) ) are missing some of the background and nuance of URIs for physical things. I've been reading up on these things and (hopefully) understand the landscape a little better now.

• https://www.w3.org/TR/cooluris
• https://www.w3.org/2001/tag/awwsw/issue57/latest/
• https://blog.iandavis.com/2010/11/a-guide-to-publishing-linked-data-without-redirects/
• http://ukgovld.github.io/ukgovldwg/recommendations/uri-patterns.html
• https://github.com/AGLDWG/guidelines/blob/master/PID-IRI-Guidelines-v2.2.md

At the risk of rehashing things discussed in the issue(#15) I'd like to state things as I understand them so people can correct me where I've misunderstood. Hopefully that might help other people like myself.

1. A PIDINST is shorthand for referring to a PID for an instance of an instrument (the physical thing).
   a) The term PIDINST also implies that this type of PID is expected to have metadata conforming to the PIDINST metadata profile.
   b) I've noticed that "PIDINST" has been referred to as meaning the Working Group (see Introduction of the RDA recommendations, "The Persistent Identification of Instruments Working Group (PIDINST) is a working group...") and as the Identifier for an instrument (in general discussions). I'm assuming the latter is the correct usage.
2. A PIDINST is an identifier. A "resource description" (Description) or "PIDINST Record" is separate. It is a description (metadata) for the physical thing and uses the PIDINST metadata profile.
   a) This follows conventions and recommendations in things like URIs for Real World Objects (particularly Requirement #2 "Be unambiguous"), Providing and Discovering URI Documentation and UKgovLD recommendations.
3. It is convenient (on the web) to have a Description returned by the PID (of the physical thing) so people can discover information about it.
4. In the PIDINST metadata schema, the Identifier attribute is the PID of the instrument that a Description is describing i.e. relationType Describes.
   a) To re-state that, the Identifier is not the identifier of the metadata record. However it is useful to have the Instrument PID return a Description.
   b) And, for that description to be a generic standard that has the flexibility to allow you to resolve related links to get to other descriptions and resources.
   c) Aside: This last point was an important realisation for me. I need to stop thinking that the PIDINST schema needs to be a container for all information and rather that it is an intermediate stepping stone to other information and that it is an opportunity to have an interoperable (standard) stepping stone. The recommendations doc section 2 mentions that quite clearly.
5. The resource description itself may have it's own PID (or not depending on implementation but probably really nice if it does). This is the property I'm proposing

I would really welcome any correction or clarification on those statements.

If my understanding of things above is correct then I feel like a property for the identifier of the metadata record itself is a good idea.

---

Drawing a line under that and moving on to speculation about the implementation PIDINST's (identifiers) and PIDINST records and relating them.

For my use case I am imagining resource descriptions for PIDINST's having their own (versioned) URI's and that an instrument PID could resolve to the latest version of the Description (PIDINST metadata record).

Perhaps the use of multiple versions of the description (PIDINST metadata record) to describe a PIDINST is in fact already the intent and well established and I just haven't understood this to date?

It would be useful for me to know if the following contradicts the intent how PIDINST might be practically implemented.

Again, I realise this is somewhat at the implementation level but it ties back to what properties are in the schema, how you use them and how you can discover the related information. For example, if a PID always resolves to the same description and the client needs to interrogate attributes to determine whether the record has been replaced with a new version and then follow and resolve that to find the latest description or whether a PID always resolves to the latest description and a client can follow relatedIdentifier to build the history of the description. Either of these are reasonable use cases and I'm trying to understand whether the properties in the schema support that.

The instrument retains its Identifier - it is the physical thing and it exists. It's just that when we resolve the PID we get a different resource description - because the description of the thing has changed.
The RelatedIdentifer and relationType:IsPreviousVersionOf would serve to link back to the previous resource descriptions. Although I would need some temporal context so that I knew which of the previous versions of descriptions is relevant for a particular date or date range. i.e. for a PIDINST metadata record what is the range of time that it is the applicable description for the instrument. To be clear, these are previous versions of the description not previous versions of the physical instrument. A previous version of the description might have a different owner or a different related component (which could well describe a physical difference in the instrument).

At present I don't see a date-like property in the schema that would support that? Something to be able to indicate dates relating to the metadata record itself rather than the instrument.
If that is down to users to implement themselves by extending (sub-classing) the schema or via related records then that could be ok. It would be useful for me if that could be spelled out in recommendations.

I know there will be different use cases but I feel like this (versioned descriptions for a constant PIDINST) makes sense for a lot of my work (and conforms to patterns used for many semantic web implementations). I would continually refer to an instrument by one identifier. That wouldn't necessarily preclude me from creating another (replacement) PIDINST for the same instrument (perhaps in the case of significant physical modification) but it would not require me to create a new PIDINST in order to have a series of modified descriptions over time. It does perhaps have the complication of being able to distinguish between "IsNewVersionOf the Description" vs "IsNewVersionOf the instrument"?

For myself it helps to frame things in terms of how I might practically implement them. So some links for an imagined implementation:

PIDINST for an instance of a camera:
https://www.example.com/pidinst/id/camera001

PIDINST redirects and dereferences to a PIDINST Description (which uses the PIDINST schema):
https://www.example.com/pidinst/doc/camera001

Which might default to return a default format and default version :
https://www.example.com/pidinst/doc/camera001.20220504.html
Idenitifer in this record for the PIDINST it is describing is https://www.example.com/pidinst/id/camera001
The URI for this PIDINST description itself (the property proposed in this issue) is https://www.example.com/pidinst/doc/camera001.20220504

The PIDINST Description can have alternate representations:
https://www.example.com/pidinst/doc/camera001.20220504.json
https://www.example.com/pidinst/doc/camera001.20220504.xml
https://www.example.com/pidinst/doc/camera001.20220504.ttl

The PIDINST Description can have other versions:
https://www.example.com/pidinst/doc/camera001.20210203
https://www.example.com/pidinst/doc/camera001.v0_1_3
Each of these have their own URI but the same Identifier because they all describe the same instrument.
Ideally these records would have a property to indicate what they are superseded by and when.

If anything I mentioned warrants the creation of a separate issue please let me know.

[huberrob]

Hi Erin,

Not sure if I correctly understood your comment, but I don't think we need an ID for the PIDINST record itself, since the metadata schema was explicitly defined for the registration of instrument instances for which the PIDINST is assigned. Thus, the metadata record and the PIDINST belong together in the same way that a DataCite metadata record and a DOI belong together.
Regarding the 'physical linking' between the actual instrument and a digital record you might find useful thoughts in the draft whitepaper here: https://rda-pidinst.readthedocs.io/en/latest/white-paper/index.html

Robert

[ErinKenna]

Thanks for your reply @huberrob .

Greatly appreciate any advice from the community on how to make this work.

I have an instrument with a PID (that PID is also printed as a QR code onto the body of the instrument).
When resolving the PID it redirects to a (PIDINST) metadata record.
I've now changed something with the instrument (e.g. different owner, updated firmware, replaced camera lens) and want to update/replace the metadata record (whilst still having a record of it's previous state).

They way I see (and would like) to do that is to use a PID for the metadata records (not an instrument PID just a PID for the document). I create another metadata record, the instrument PID now resolves to this new document and add a pointer in the document links the previous version of the metadata.

If I can't do that then how should I be implementing changes to the metadata and having a history?
My impression, from the PIDINST docs, is to either modify the metadata record (no history?) or change the PID of the instrument and create another PIDINST metadata record that has a pointer to the previous instrument PID - this would require replacing the physical QR code on the instrument.

I crossed the above out but I'm leaving it in case it is useful for anyone going through the same thoughts I had.
I am now thinking the following.

I should simply keep the information in the PIDINST metadata record very minimal.
Rather than trying to overload the relationType with component information (and thereby requiring making updates to it) I should just use the relationType:isDescribedBy to point to my description PID. Thus defer the system of alternate representations and versions (described in the example in my original post) to that document rather than the PIDINST record.
Sorry that may be confusing.
Essentially;

• Accept that a major change in the PIDINST description might require a new PID for the instrument (and an update of the physical label on the instrument).
• Minimise the chances of this occurring by keeping the contents of the PIDINST record minimal.
• Accept that the PIDINST record does not have a PID.
• Use the relationType:isDescribedBy to point to the PID of my description.
• Use that description to have the rich information and manage changes in metadata versions,
• also use that description for document PIDs and linked data semantics around resolving to current description, multiple versions and multiple representations (xml, json+ld, etc.).

I think that will work.

Thanks, Erin