Deprecation of terms referenced from multiple registers

[6a6d74]

[for discussion regarding additional tools required to support register management]

The summary point is that tools like a "back-link" service (to identify where else a term is referenced) or a "watch" service (to notify a user of a change to a given term/register) will be extremely useful when managing a registry.

---

Question (from Andrea Splendiani):
What do you do when you obsolete a term that is contained in more registries ?

The situation is this:
you have a register for runaways:R
And have a term:1
hence our URI is R/1.

Now, as far as we keep containment and definition tight together, if we obsolete a term, this means it's out of the registry.

Now:

you have a register for Runaways certified to be good when wet: RCW
You add your new term to RCW.
So we have RCW contains R/1

What happens if you obsolete R/1 ?
It's easily reflected in R
What about RCW ?

In our previous model this was and wasn't an issue, in that by definition register could "contain" only entities they defined, while other entities could be differently related.
E.g.: RCW was a collection, otherwise basically an "entity" subject to versioning, that would contain obsoleted terms (without logical problems) until amended.

It may be that after all you still have a difference between definition and containment emerging.

---

Response (from Jeremy Tandy):

Your question (summarised): "what happens to register RCW when term R/1 is obsoleted in register R"

If you look at the information model [ https://github.com/der/ukl-registry-poc/wiki/Principles-and-concepts#wiki-model ] you will see that "status" is a property of the register item, which provides the metadata about the relationship between a single entity and a single register.

So when the register manager decides that term R/1 is no longer appropriate in register R, she will update the status of term R/1 with respect to register R.

Thus the register item associated with term R/1 (let's call it R/_1 using our preferred notation) now has properties like:

<R/_1>
a reg:RegisterItem ;
reg:register ;
reg:definition [ reg:entity <R/1> ] ;
reg:status reg:statusRetired .

Notice that term <R/1> still exists ... it's just that in the context of register it is no longer valid; I've used "statusRetired" to indicate this.

This does not affect register ; the register item* will still show properties such as:

<RCW/_6>
a reg:RegisterItem ;
reg:register ;
reg:definition [ reg:entity <R/1> ] ;
reg:status reg:statusValid .

• note that the register item identifier need not match the identifier of the registered entity itself; here let's assume that term <R/1> is the sixth term registered within .

Updates to register require some additional processing.

One of the additional tools that we expect to layer on top of the register is a "back-link" service that would enable one to quickly find all the entities within the register that refer to a given resource. Thus a "back-link" query against term <R/1> would return the two register items <R/_1> and <RCW/_6> which can then easily be investigated to determine the register that they are associated with. Thus the register manager (if they have the necessary permissions) could update register as necessary.

Alternatively, we also want to introduce a "watch" tool that allows interested parties to request notification if a term (etc.) is updated. This could be used to notify the register manager of who could then take the appropriate action.

[der]

Largely agree but this is not the full back-link service, just entity retrieval and that's already in the spec.

So a GET on http://registry/?entity=<http://registry/R/1>&_view=with_metadata should return all occurrences of R/1 in any register under the root register (i.e. all of them). Can also filter by status. As it happens this is a part I'm working on at the moment and was just wondering of "with_metadata" support is needed, sounds like it is.

The back-link stuff is more about when people externally refer to your term in some dataset. Even if they register the dataset the fact that the dataset uses a term isn't directly known to the registry without the extension work on pingback and dataset analysis.

Concur that a watch service is required. Plan for the extension is to move the internal architecture to be message-oriented with support for pub/sub.

[der]

The entity search is now implemented and I've captured a summary of this use case on FAQ list https://github.com/der/ukl-registry-poc/wiki/Faq

Can we close the issue?

[6a6d74]

Happy to close.