-
Notifications
You must be signed in to change notification settings - Fork 1
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
Need to constrain iderdown queries to appropriate dataset #21
Comments
Each "dataset" is considered to be a
So each entity is a member
These are different things. Furthermore, lower level datasets are also a member of a higher level register, e.g.
so if you want to constrain the query to the higher level datasets, then the query will have to include a property-path |
Looking at what datasets are present:
which results in
i.e. the GNAF datasets are not dated. |
Other examples:
|
OK. Totally agree this is the way to do, thanks for confirming it @dr-shorthair. The big task before we can do this of course, is getting all the datasets to conform to this approach... I will get into it. |
I though I would address this when looking into a refactor of the LDAPI's. Unfortunately the refactor didn't get far enough to replace all the LDAPI's so it isn't the solution I was hoping for. Just flagging this stuff is still an issue. Mainly, it's an issue because of the inconsistent was |
Partly related: The problem Nick was trying to resolve was the absence of a standard property that is the inverse of At the end of the day what I think we need is Just discussed this f2f with Jonno, and will attempt to rationalize all this in https://github.com/CSIRO-enviro-informatics/loci.cat/wiki/Rules-for-Loc-I-datasets Note:
rather than as individuals, like
which is the way we have done it and is failry conventional. Meta-modelling often ends up with axle-wrapping ... |
@dr-shorthair on "I don't think we need reg:Register anywhere" The issue is that this is baked into the pyldapi library (see https://github.com/RDFLib/pyLDAPI/blob/master/pyldapi/register_renderer.py#L224) For this to change, we'd need to change that bit of code which renders items as |
Hmm. Well that indicates a modelling error in pyldapi IMHO. The Register ontology is clear - register items are metadata records, not data items. |
Is there an alternative to the Register ontology that can be proposed? It would need to be generic (like not just Dataset items) |
Yeah - that is the issue. As discussed the other day, I think the membership predicate is easy - For the container I think the options are
But I think I'd be inclined to go with |
For Loc-I, probably dcat:Dataset would be fine. However, the pyldapi library's scope is more general than that I believe. might be good to push some requirements to that library from loci. |
Currently the queries are not constrained to the specified dataset. This can result in cross dataset issues, for example GNAF and GNAF16 use the same uris for base types, and thus if both datasets are in the cache, things could get confused.
The text was updated successfully, but these errors were encountered: