search

UKGovLD / registry-core

Linked data registry - core application and example UI
https://github.com/UKGovLD/registry-core/wiki
Apache License 2.0
23 stars 9 forks source link

dynamic membership #115

Open marqh opened 5 years ago

marqh commented 5 years ago

A register may be defined, including:

for example:

<register> a skos:ConceptScheme ;
                 ...
                 ldp:isMemberOfRelation  skos:inScheme .

or

<register> a skos:Collection ;
                 ...
                 ldp:hasMemberRelation   skos:member .

Once the register is defined, individual elements may be added to this ConceptScheme/Collection

This is a very useful work flow for ongoing management of content.

During this individual registration, no update is made to membership semantics, whether skos:inScheme for individual members or skos:member for the ldp:Container

This is in sharp contrast to bulk:registration, where these relationships are required for bulk upload.

This then drives differences in behaviour, for example, download will only download the container, not its members.

Questions:

  1. Is it intended functionality that individual element registration and bulk-registration result in the same content with the same functionality?
  2. How easy would it be to implement the addition of this membership relationship during individual entity registration?
  3. Are there work flow ideas to work around this, providing a mechanism to register element by element, whilst creating the membership relations during registration?
    • For skos:ConceptScheme this can be implemented using an empty element <> for the object of the skos:inScheme statement.
    • For skos:Collection, the register would need to update itself with new skos:member statements during upload.
    • Similarly for other member and inverse member relations, I presume
  4. What would be the problems and unintended negative consequences of implementing such an update during registration?

(@der ) Dave: do you have some insights on this that you would share with us please?

der commented 5 years ago

It should certainly be possible to add individual members to a collection and have them appear as members with the appropriate membership relationship being included in responses.

As illustrated by the second diagram in https://github.com/UKGovLD/registry-core/wiki/Principles-and-concepts#information-model the design of the registry is that internally the presence of an item in a register is defined by the reg:register link between the register item and the register. This is created whether as a result of a bulk upload or of an individual entry. When the contents of a register are returned from the API the chain ^reg:register/reg:definition/reg:entity is used to locate the members and then the appropriate direct or inverse membership property is added to the returned payload. So the membership properties are "virtual properties" inferred from the registry metadata structure.

If this isn't working then that sounds like a bug in which case a specific test case would be helpful in order to investigate further. Worth checking that this is not another example of the status filtering causing issues - clearly if the new member is in a non-accepted status (i.e. submitted) that it would not appear.