"Reserved" register items are invisible! Do we need a "Reserved" entity as proxy until the real entity is assigned? about ukl-registry-poc HOT 8 CLOSED

Regarding the idea about setting the register item to a pre-defined "reserved" entity; it is not at all obvious how the reg:entity could be updated, nor whether this action should be permissible! The issue is that I would want to upload a new managed entity into the register and assign this to the existing register item (rather than the upload creating yet another register item).

Thoughts?

from ukl-registry-poc.

I think this is now resolved. There was a mix off missing features and bugs here.

First off the reason that the reserved member was not shown in the register is because the listing code assumes that (amongst other things) all entity entries have the minimum required properties of @Rdf:type@ and @RDFS:label@. So a plain bNode fails that but was not rejected at registration time due to the lack of the registration validator (my next job).

So an example correct reservation registration would be:

@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dct:     <http://purl.org/dc/terms/> .
@prefix reg:     <http://purl.org/linked-data/registry#> .
@prefix skos:    <http://www.w3.org/2004/02/skos/core#> .

<>
      a       reg:RegisterItem ;
      rdfs:label "Reserved"@en ;
      dct:description "Reserved for future use"@en ;
      reg:definition
              [ reg:entity [a skos:Concept; rdfs:label "reserved"]
              ] ;
      reg:itemClass skos:Concept ;
      reg:notation "six" ;
      .

Given that then the entry is made and appears in register listings.

[In the deployed code this does not work as you expect. The bNode for the entity is rewritten to match the given notation. I have changed this is the working code base so that the bNode is left as a bNode.]

Having made that reservation it is then possible to change the reserved entry to given it the correct label and entity URI (and any other metadata of course). For example PUT/PATCH to {register}/_six of:

@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dct:     <http://purl.org/dc/terms/> .
@prefix reg:     <http://purl.org/linked-data/registry#> .
@prefix skos:    <http://www.w3.org/2004/02/skos/core#> .

<_six>
      a       reg:RegisterItem ;
      reg:definition
              [ reg:entity <http://example.com/six>
              ] ;
      .

<http://example.com/six>
    a skos:Concept;
    rdfs:label "six"@en;
    dct:description "The number six, two times three"@en;
    .

This step will fail in the deployed system because of some bugs, which are fixed in the main code base.

So I think this provides the functionality you were expecting.

The outstanding tasks here are the validation steps. Currently you can do the PUT/PATCH to update the entity URI at any time whereas it is only supposed to be allowed for entities of status @reg:NotAccepted@.

I'll work on the validation machinery for both this aspect of update and registration in general.

from ukl-registry-poc.

P.S. Note that we could automate the creation of label and type information for the reserved bNode from the RegisterItem. I would rather not (I'd like to avoid too much special case behaviour like that). Rather it would make more sense to me that when reserving an entry you use a payload more like:

@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dct:     <http://purl.org/dc/terms/> .
@prefix reg:     <http://purl.org/linked-data/registry#> .
@prefix skos:    <http://www.w3.org/2004/02/skos/core#> .

<>
      a       reg:RegisterItem ;
      reg:definition [
          reg:entity [
              a skos:Concept;
              rdfs:label "reserved"
              dct:description "Reserved for future use"@en ;
          ]
      ] ;
      reg:notation "six" ;
      .

Which avoids the apparent duplication.

from ukl-registry-poc.

Thanks for the updates.

When do you expect to deploy the new version of code? I would be happy to flush the registry (e.g. clear-down) at this point & start testing from a clean sheet once again.

I agree with avoidance of special cases; I am happy to create the blank node (with included properties as indicated above).

I might also add:

[] skos:broader <ukgovld-registry.dnsalias.com/reserved> .

into the definition to indicate that this bnode-identified entity is related to the entity I created earlier; this way one might be able to quickly find all "reserved" entities [???].

Regarding the validation (e.g. one can only PUT/PATCH to update the entity URI whilst status "not accepted" (e.g. submitted, invalid), in their code-tables, WMO sets "reserved" entries as "operational" ... which I think is quite odd. However, I think that what we're seeing here is two different types of status being employed. I'm minded to create a separate wmo-status property (for the register item) for this purpose that can be updated like any other property. There would be no special behaviour relating to such a wmo-status property; no impact on software implementation ... it's just a simple property that states "operational" or "validation".

from ukl-registry-poc.

Great, so I think we are about done on this issue. I figure a way to mark as "pending review" since you'll want to test on new deployment before being sure it does what you want.

Re: new deployment, my preference would be to address a few more of your issues first, aim to redeploy first thing next week.

Re: status. Having a separate wmo-status makes sense. I'd also be happy to lift (or rather not implement) the restriction on not changing the URI of accepted entities. It could be simply the job of the normal register approval process to decide if each instance of such a change is reasonable rather than rigidly enforce in the automation.

from ukl-registry-poc.

Dave. I propose that you proceed to implement the constraint such that a
reg:RegisterItem with status "valid" (or subtype thereof) cannot have the
reg:entity property updated.

In situations where the reg:entity needs to be updated and the status is
valid I suggest that administrators would need to update the status back to
"submitted" (e.g. using the "force" option) and then make the change.

I would rather avoid making special cases to allow reg:entity update in
"special circumstances".

For WMO we may set the item status of a reserved entry to valid (to match
the "operational" WMO status) and then use the method outlined above to
reset the entity when the identifier is finally allocated.

Jeremy
On 21 Mar 2013 21:29, "Dave Reynolds" [email protected] wrote:

Great, so I think we are about done on this issue. I figure a way to mark
as "pending review" since you'll want to test on new deployment before
being sure it does what you want.

Re: new deployment, my preference would be to address a few more of your
issues first, aim to redeploy first thing next week.

Re: status. Having a separate wmo-status makes sense. I'd also be happy to
lift (or rather not implement) the restriction on not changing the URI of
accepted entities. It could be simply the job of the normal register
approval process to decide if each instance of such a change is reasonable
rather than rigidly enforce in the automation.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/33#issuecomment-15266737
.

from ukl-registry-poc.

Thanks Jeremy: that makes sense. Now done.

from ukl-registry-poc.

I will test the behaviour once the new version is deployed next week.
Thanks! Jeremy
On 22 Mar 2013 16:37, "Dave Reynolds" [email protected] wrote:

Thanks Jeremy: that makes sense. Now done.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/33#issuecomment-15307184
.

from ukl-registry-poc.