Limitations of pyLDAPI which need addressing before rollout.

[ashleysommer]

Look at this output of the current implementation of the GNAF Register of Registers: https://pastebin.com/raw/QpL4iPYx

You will notice there are triples in that output that currently the pyLDAPI cannot be configured to output.

For example, this is what the same RofR would look like as ouput by the current version of the pyLDAPI: https://pastebin.com/raw/UiMc3krd

Comparing the two, notice:

• There is no current ability to specify a Class other than reg:Registry for the RofR, but the GNAF RofR specifies a class of dcat:Dataset as well as reg:Registry
• The pyLDAPI can configure what values to fill for the RofR's Comment, Label, and ContainedItemClass list, however there is no ability in the pyLDAPI to specify extra predicate-object pairs for the RofR, such as dc:creator, contributor, publisher, modified, source, etc, as seen in the GNAF output.
• When listing items in a Register (in this case, subregisters in the RofR), pyLDAPI will only list the URI with it's specified Class, its parent reg:register, and optionally its rdfs:label if one is supplied. There is currently no mechanism to add extra predicate-object pairs to each item, such as the reg:containedItemClass as seen in the GNAF RofR. Note this final issue also affects other generated registry listings, not just an RofR.

[ashleysommer]

@nicholascar I need to know whether it is important to address these limitations (by adding these features to the pyLDAPI) before rolling out the pyLDAPI to our implementations.

[nicholascar]

For each of the three points above in order:

1. The overall issue here is that the relationships of registers of things to datasets of things isn't worked out yet.

So, just generate what you can with the RofR as a reg:Register and ignore all dcat:Dataset and similar properties. We will need to work out some convention like pyLDAPI installations auto-generating a top-level register that is, itself, just a reg:Register and what you see as the dcat:Dataset object here will have to be another object. Perhaps in re-doing the GNAF, make the RofR at linked.data.gov.au/dataset/gnaf/ and the dcat:Dataset declaration for linked.data.gov.au/dataset/gnaf (no trailing slash). We can then think of a way to link the two perhaps with a static declaration in the dataset of <http://linked.data.gov.au/dataset/gnaf> dct:hasPart <http://linked.data.gov.au/dataset/gnaf/> . and/or a way to inject additional triples into the RofR graph to allow for <http://linked.data.gov.au/dataset/gnaf/> dct:isPartOf <http://linked.data.gov.au/dataset/gnaf> . We may think of better relationships than dct:hasPart/dct:isPartOf later.

2. As above, push these out of the Rof R and delegate them to the Dataset object which can be static for now, as it currently is in the index.ttl file.

3. I think we really need reg:containedItemClass for all registers starting with the RofR (where the reg:containedItemClass is, of course, reg:Register) so when building the RofR, the method used to interrogate the other Registers in the API is going to have to ask those registers for this info also.

[ashleysommer]

3. is fixed by https://github.com/CSIRO-enviro-informatics/pyldapi/commit/04e0159a9b9b70093958b29c39b6c63784ef2abd