Discussion om concept UCD: meta.ref.pid

[Markus Demleitner]

hi,

On Tue, Nov 09, 2021 at 09:38:26AM +0100, Molinaro, Marco wrote:
> Most PIDs are URIs (handles included).
> IVOIDs, e.g., are URIs.

Well, let's say "they can have a URI form", but I don't think that is
a very important property by itself; now that I think of it, I guess
the most concise definition of PID would be "Some string you can feed
to a resolver to obtain... (something; this part is a bit
difficult)".  When you have URIs with schemes, you can communicate
which resolver to use, but where the context says which resolver is
appropriate, that's not a big advantage.

> I'm thus wondering if adding new UCDs
> for handle.derived PIDs is a good choice
> (as of now I would lean towards "yes")
> or if something else will be needed in
> the future.
> 
> Could it work something like... ?
> 
> P meta.ref.uri (already there)
> 
> with
> 
> meta.ref.doi - meta.ref.epic - etc...
> 
> as S words?
> (means moving towards meta.ref.uri;meta.ref.doi)
> 
> keeping meta.ref.ivoid as Q for
> "domain" reasons?
> 
> Unfortunately meta.ref.doi,
> currently a P word, complicates
> things...
> 
> Don't know, quite confusing.
> (I'm hearing a whispered "...bring the use cases...")

I think the use case here is pretty clear: A client that sees
meta.ref.pid knows "this is an opaque (to me) string that can lead to
some (realistically, web) resource when fed to the proper resolver".
If the client happens to know the context and hence the resolver to
use, it can give the user a clickable button to retrieve that
resource (or a description of it).  Otherwise, it can offer the
string for copy-pasting into a resolver by the user.

meta.ref.doi provides such a context for a common case, and a client
can just prepend https://doi.org and has the URI that the button
would open.

Perhaps other cases where we want to have canned context will come in
the future, but until then I'd say just the general signal "if you
happen to know the sort of PID, make a link, else offer
cut-and-paste" ought to be enough.

> Maybe adding meta.ref.pid (Q?, S?, P?)
> would suffice.

Given these considerations, I'd say yes, and it should be a P,
because it determines the action to take.

It *would* be nice if we *could* say something like

  meta.ref.pid;meta.bib.author

to be more specific on what sort of thing is referenced.  But alas,
meta.bib.author is P.  If I built the thing again, I'd quite
certainly introduce an S concept meta.author, "related to an author",
and then "author name" would be meta.id;meta.author.

But we can think about evolution in that direction once clients
actually do something meaningful with meta.ref.pid.

Thanks,

          Markus