New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ror file as defined in INSPIRE #5
Comments
Adding metadata-only endpoints for registers and a metadata endpoint for the registry itself is feasible and may be a generally useful extension. Such endpoints could deliver the usual RDF formats, including RDF/XML. If the ROR specification allows ROR consumers to ignore properties they are not interested in, then once there are metadata-only endpoints you would just need to add the metadata corresponding to ROR on top of the the normal registry metadata. If the specification (which isn't precise on this point) requires "these properties and only these properties" then that would be a different situation and would require a ROR specification solution that seems less appropriate for the main code line. |
The validation process used (https://ies-svn.jrc.ec.europa.eu/projects/inspire-registry/wiki/Registry_federation_xsl_validators) excludes several prefixes. |
Testing the example files with INSPIRE xsl, the .ror for the register (litho.ror) initially did not pass register descriptor validators for several reasons listed below
|
Comments and clarification questions ... So there's several parts to this problem - the need to include the full publisher information and The publisher and registry link information can't be included in a register definition without modifications to the codebase. You can uploaded embedded information by using blank nodes but the ROR validator doesn't accept those and indeed the ROR spec explicitly asks for URIs as well as inline descriptions of them. It would be possible to have separate registers (e.g. under After some experimentation I think the XML serialization issue itself is solvable. The validators have a very narrow view of RDF/XML but we can configure the Jena RDF/XML writer to pull The ROR specification includes a separate media type for ROR files so the right approach is probably to add a The ROR requirements over use of Some questions:
|
Thank you very much Dave, the solution of a separate registers (e.g. under structure) seems the most suitable way I think. We agree with your proposition of a selective control using this separate register. I think it's easier for the dev and better for us since we want to have an individual control on what registers should be pushed through ror. It's even better this way since we can have different properties (e.g. producers and different periodicities) from one register to antother. |
JRC reply: Currently the RoR is just using the English language as first choice. If this is not found, it tries to read the first occurrence without specifying the language. |
@der have there been any advances about this issue. |
@afeliachi I am currently working on this issue now that the internationalisation feature appears to be in a good state. I expect that it will be ready to test by the end of this week. |
Thanks Simon. We would really appreciate that. |
The branches for this feature on I had to differ from some of the plans discussed above in order to make sure that the produced XML would conform to the given templates (the default serialisation tends to produce valid RDF but not in the required structure). In particular, the registry descriptor and the root ConceptScheme of the register descriptor will be rendered with only the properties that are relevant to the INSPIRE format. This is currently a hard coded list, so please let me know if you need this to be configurable or if there are specific properties you would like to include. |
Have you made any progress in testing this? |
Sorry Simon I thought I responded to this.
thank you |
@afeliachi OK, I will try to look into this in the next week or so. |
|
Hi Simon |
Hi Simon
It is necessary to have
So I tried to edit the root directly, by adding the
I get the same response with (PATCH request) to update the root description. Do you have any suggestion on that.
|
Thanks @afeliachi , I will look into point 2 this week. |
Thank you @simonoakesepimorphics |
I've updated the branch to satisfy the requirement that the registry descriptor should have the root register as its root element rather than the The registry description and dataset catalog resides on the Register descriptors should work the same as before. I've updated the wiki page to reflect this. |
Hi @simonoakesepimorphics |
Dynamically generate .ror files as specified by INSPIRE group on register federation:
More details and example files here: https://ies-svn.jrc.ec.europa.eu/projects/inspire-registry/wiki/Registry_federation_requirements
Running examples (hand-made for BRGM registry)
Idea would be to have the required 'descriptors' natively included in the description of the registry and the registers -> no more need for static files but need to have a new 'download format' (like RDF/XML.ROR) that triggers the required response/serialization
The text was updated successfully, but these errors were encountered: