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: https://github.com/rdawg-pidinst/schema/issues/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(https://github.com/rdawg-pidinst/schema/issues/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.