Create true persistent identifier for notices

[jdeck88]

(extracted from conversation on a zoom chat during an iSamples RCN meeting on May 30th)

Pier Luigi: does LC have a persistent ID?

John Deck: pier — no, not yet for PID for the notices… for now its just a URL resolved using a local contexts project id, e.g. https://localcontextshub.org/projects/259854f7-b261-4c8c-8556-4b153deebc18/
there is an associated publication DOI metadata attribute for the project.

Pier Luigi:
Thanks - this is an important thing to get done, but it shouldn't be claimed if not in play
w3ids can be set up quite quickly

John:
Opening up this issue to begin exploration on assigning a pid for labels. (pier mentioned w3ids for this, i think the easiest way is to use w3id top level ID for local contexts landing page and add lc id as a sub-level identifier. this should be very simple to implement... happy to help more on this)

[pbuttigieg]

Thanks @jdeck88 - having solid PIDs would greatly help with our LC-ODIS work to get linked data implementations in shape and sustainable. Cross-linking: iodepo/odis-arch#398

[arojas1]

Hi @jdeck88 and @pbuttigieg, The LC Project URL acts as a URI for Notices and Labels associated with that Project. We hesitate to making individual PIDs for Notices or Labels that others can use independent of a Hub Project. If a PID for a Notice is created and is referenced independent of a Hub Project, there would be no way for a Community to respond to that Notice with their customized Labels. Because the Notices and Labels are assigned based on Project scope, the individual Label PIDs would become independent to it's associated item(s), collection, dataset, etc. and would lose the Community's decision on what Label(s) should be associated with that Project's scope.

If there is a way to make sure that the Notices or Labels are always referenced in association with the Project and never able to be referenced independently, then I think that would make sense, but once removed from the Project, the purpose of the application becomes irrelevant.

[pbuttigieg]

@arojas1 - thanks for the context.

I'm thinking more a PID for the label class itself, rather than instances (although those could benefit from a PID too). Some in line responses:

The LC Project URL acts as a URI for Notices and Labels associated with that Project.

I don't think this is good practice - a URI should point to one thing. That thing can be linked to other things (e.g. projects to documents), but those linked things should have their own identities. Otherwise one can't be sure what one's talking about.

We hesitate to making individual PIDs for Notices or Labels that others can use independent of a Hub Project.

If one implements the metadata well, you can hard link the Notice/Label to the Project without convoluting the types.

If a PID for a Notice is created and is referenced independent of a Hub Project, there would be no way for a Community to respond to that Notice with their customized Labels.

Again, I think this is more a question of how you implement. PIDs can reciprocally reference each other (often done), and platforms like the Hub can pick that up and propagate responses.

Because the Notices and Labels are assigned based on Project scope, the individual Label PIDs would become independent to it's associated item(s), collection, dataset, etc. and would lose the Community's decision on what Label(s) should be associated with that Project's scope.

Again, I don't think this is necessarily the case. In fact, you already have some form of identifier for each individual label, they're just not formed in a FAIR way. The decisions of association are immutable - in fact you can weave together the PIDs for Labels, Notices, Projects, etc in a record that expresses those decisions (with its own PID). As long as you have a trusted authority managing those PIDs (like Local Contexts), things should work very well and allow fine-grained (meta)data exchanges and referencing.

If there is a way to make sure that the Notices or Labels are always referenced in association with the Project and never able to be referenced independently, then I think that would make sense, but once removed from the Project, the purpose of the application becomes irrelevant.

There is - but they can be referenced independently in a strict sense, but the metadata on the other end of that reference can be hard-linked to everything else you want to be associated with the subject entity. This is tried and tested linked data.

[jdeck88]

I'd like to offer a brief JSON response below (abbreviated LC response).

1. The following can be returned by:
   https://somepid_root/35449cb1-7ae9-410d-a6c0-1d2deb874e6b
   where somepid_root equals "https://localcontextshub.org/api/v1/projects/"

2. The notice_pid below is a field describing biocultural notices in general:

{
    "unique_id": "35449cb1-7ae9-410d-a6c0-1d2deb874e6b",
    "title": "Metapopulation structure of Intertidal Invertebrates",
    ...
    "notice": [
        {
            "notice_pid": "doi:some_link_to_describing_biocultural_notices",
            "name": "Biocultural (BC) Notice",
            "img_url": "https://storage.googleapis.com/local-contexts-hub.appspot.com/labels/notices/bc-notice.png",
            "created": "2022-12-30T06:28:33.796144Z"
        },
        ....
    ]
}

So, Pier, can you turn this into JSON-LD and using the notice_pid as an identifier for the biocultural notice. We want any labels, also to have an identifier. Lets getting a working JSON_LD response here in this comment and then we can build it out for an example that includes multiple labels...

[jdeck88]

Inserting conversation from email here:

On May 31, 2024 @arojas1 wrote:
Can I ask what would be the use case for template Labels needing to be referenced using a PID? To me it seems irrelevant if we want the customized Labels to be what holds weight on a dataset.

On May 31, 2024 Jane Anderson wrote
The reality is that we cannot have a doi for every label customized and especially since they are mutable (could change text at a community level). This is why, for customized labels there is the Project ID which will always point to the mutable set of community labels. But for the actual labels and what they point to - these should have a DOI so even in 40 years there is a resolution to at least a stable original version of the label which makes clear the intent. Then we are also not creating DOIs for every label ever created. We just need a doi for all currently developed labels and template text.
Does that make sense? It is a double back up.

John Deck inserting comment here:
So where we land on this is to create a PID for each label that as Jane says points "... to at least a stable original version of the label which makes clear the intent". And this way, when labels are used on the web (and expressed as JSON-LD) we always know which type of label was applied. Again, this is not a PID for the customized mutable label but the original version of what we call "BC-Provenance", or "TK-Notice", etc.... These references are what would be inserted as values in the "notice_pid" attribute. @pbuttigieg hopefully can provide better JSON-LD syntax. I've included chatGPT's JSON-LD rendering of my above JSON below (what better way to get machine interoperability than to ask a machine to provide the syntax :) ):

{
  "@context": {
    "@vocab": "http://schema.org/",
    "dcterms": "http://purl.org/dc/terms/",
    "bcNotice": "https://storage.googleapis.com/local-contexts-hub.appspot.com/labels/notices/bc-notice.png"
  },
  "@type": "ScholarlyArticle",
  "@id": "https://doi.org/35449cb1-7ae9-410d-a6c0-1d2deb874e6b",
  "identifier": "35449cb1-7ae9-410d-a6c0-1d2deb874e6b",
  "name": "Metapopulation structure of Intertidal Invertebrates",
  "notice": [
    {
      "@type": "CreativeWork",
      "@id": "doi:some_link_that_describes_the_original_version_of_biocultural_notice",
      "name": "Biocultural (BC) Notice",
      "image": "https://storage.googleapis.com/local-contexts-hub.appspot.com/labels/notices/bc-notice.png",
      "dateCreated": "2022-12-30T06:28:33.796144Z"
    }
  ]
}

interestingly, Chat converted img_url to image and created to dateCreated -- not sure if these names are a meaningful change in the world of JSON-LD or not.

[pbuttigieg]

Hi @jdeck88 - we're developing syntax label-by-label here: https://github.com/iodepo/odis-in/blob/11-create-localcontext-examples/dataGraphs/thematics/projects/graphs/local-contexts-project-example.json

@arojas1 is parsing the labels and we're making sure we map them to the schema.org property that best expresses their nature. We're adding syntax for multi-lingual support.

Many of the labels will be in the publishingPrinciples property:

 "publishingPrinciples": [
    {
      "@type": "CreativeWork",
      "name": [
        {
          "@language": "{language_tag}",
          "@value": "{Notice Title}"
        },
        {
          "@language": "{language_tag}",
          "@value": "{Notice Title}"
        }
      ],

Others will be corrections:

"subjectOf": {
    "@type": "CorrectionComment",
    "name": [
      {
        "@language": "{language_tag}",
        "@value": "{Label Title}"
      },
      {
        "@language": "{language_tag}",
        "@value": "{Label Title}"
      }
    ],

others will be in the ethicsPolicy property:

  "ethicsPolicy": {
    "@type": "CreativeWork",
    "name": [
      {
        "@language": "en",
        "@value": "Label/Notice Title"
      },
      {
        "@language": "es",
        "@value": "Label/Notice Title"
      }
    ]
  },

There are more cases, but that's the gist

So, Pier, can you turn this into JSON-LD and using the notice_pid as an identifier for the biocultural notice. We want any labels, also to have an identifier.

in each of those types (CreativeWork, CorrectionComment), you can add an identifier property with the PID of the label in queston, but @arojas1 noted some concerns about their management.