Unanticipated behaviour when requesting version of register item. about ukl-registry-poc HOT 6 CLOSED

That does look like a defect. _versionAt returns each item and entity as it was at that time, the numbered-version view of the register should do likewise. Will investigate when I'm able to get back to the registry work.

from ukl-registry-poc.

Thanks. Also note that in current form, it impossible to correlate the entity version with the register item; e.g. I don't know when /def/colours:4 was valid ... this information is visible neither from the /def/_colours?_view=version_list nor from a specific version of the register item (e.g. /def/_colours:6)

from ukl-registry-poc.

Having just checked, "regular" entities (e.g. /def/colours/red) seem to work fine ...

Request:

curl -i -H "Accept:text/turtle" http://ukgovld-registry.dnsalias.net/def/colours/_red:5

Response (selected triples):

http://ukgovld-registry.dnsalias.net/def/colours/_red
a reg:RegisterItem ;
...
owl:versionInfo 5 .

http://ukgovld-registry.dnsalias.net/def/colours/red
a skos:Concept ;
rdfs:label "reddish" ;
dct:description "A modified concept for the colour red" .

Request:

curl -i -H "Accept:text/turtle" http://ukgovld-registry.dnsalias.net/def/colours/_red:1

Response (selected triples):

http://ukgovld-registry.dnsalias.net/def/colours/_red
a reg:RegisterItem ;
...
owl:versionInfo 1 .

http://ukgovld-registry.dnsalias.net/def/colours/red
a skos:Concept ;
rdfs:label "red" ;
dct:description "A concept for the colour red" .

from ukl-registry-poc.

I think I have spotted the problem ...

Register:
i) the register: /def/colours
ii) the register item that provides the metadata about the register with respect to the super-register /def: /def/_colours
iii) the (current) version of the register item /def/_colours: /def/_colours:10
iv) the reg:EntityReference for /def/_colours:10: _:b0 (it's a blank node)

Because _:b0 is associated with a REGISTER resource (e.g. /def/colours) it only has property reg:entity (which provides a reference to /def/colours ... e.g. { _:b0 reg:entity <.../def/colours> . }

Entity:
i) the entity: /def/colours/red
ii) the register item that provides metadata about the entity with respect to the register /def/colours: /def/colours/_red
iii) the (current) version of the register item /def/colours/_red: /def/colours/_red:5
iv) the reg:EntityReference for /def/colours/_red:5: _:b1 (it's a blank node)

In this case, the reg:EntityReference resource _:b1 is associated with a "standard" ENTITY, thus it has two properties:
_:b1 a reg:EntityReference ;
reg:entity <.../def/colours/red> ;
reg:sourceGraph <.../def/colours/_red:2#graph> .

Crucially, the register item for "standard" entity points to a SPECIFIC description of the entity, whilst the register item for a register ONLY refers to the register (a VersionedThing).

My assumption is that the registry system compiles the description of the register by concatenating the properties from the CURRENT VERSION of the register to those persistent properties from the register VersionedThing.

Proposal:

i) rename property reg:sourceGraph to be reg:source
ii) reg:source can be used to refer to EITHER a graph (for a standard entity) or a Version (if the entity, like a Register, is a VersionedThing)

This way, the reg:EntityReference resource _:b0 would have the following properties:
_:b0 a reg:EntityReference ;
reg:entity <.../def/colours> ;
reg:source <.../def/colours:12> .

In this way, sufficient information is provided to the registry to compile the requisite properties from the VersionedThing AND the Version specifically referenced in the reg:EntityReference for a given version of the register item.

from ukl-registry-poc.

It's not quite that simple :)

The version number for a Register is updated if a new item is added to make it possible to reconstruct the register state.

The version number for the RegisterItem which holds the Register is only updated when the metadata changes.

So can't have the current version RegisterItem point to a specific version of a Register, that changes.

May be possible to achieve the behaviour you want in other ways or may need to reconsider how register versioning is implemented internally. Well look at this when I'm back.

from ukl-registry-poc.

Resolved.

I already had a property reg:entityVersion intended to play a similar role to reg:sourceGraph for cases where the entity being referred to is itself a VersionedThing.

I've updated the implementation to use that to track the version of the Register present at the time (each version of) the parent RegisterItem is created.

This allows you to see the explicit version correspondence and means that when you retrieve an earlier RegisterItem version for a Register you see the corresponding version of the Register not the current version.

This does create some internal complexity that will eventually need review and cleaning. As noted in the prior comment the problem is that the Register version continues to change to reflect new members without the owning RegisterItem version changing. Rather than do expensive propagation of those changes the internal API returns either the current Register version (when fetching the current version of the owning RegisterItem) or it fetches the recorded Register version (when fetching a specific version of the owning RegisterItem (which will be the version at Item creation time)). This gives expected behaviour in all cases but isn't very satisfying.

from ukl-registry-poc.