Just wondering if anyone knows the status of the NestedDataTypes module. The last update was for v3 compatibility. I’ve asked in the issues but no response.
It solves a problem for those of us using CIDOC-CRM and its nested nature, and would save unnecessarily building out the graph (e.g. the Dimensions example given on their page), so I was wondering if there’s other alternatives?
I might try fork it, but the issues do suggest performance issues with it. Anyone had experience with using it and can verify? Any other issues?
I’ve tried it with Omeka S v3 and it worked good with smallish vocabularies. Adding schema.org made the (admin part of the) system almost unresponsive and a lot of out-of-memory errors. I think there’s some inefficient ORM going on, but lack the skills to solve (and update to v4).
Ah, glad others do see a use for it, I’m very aware we’re pushing OmekaS to do things that don’t really fit it’s original design and purpose (or indeed LoD best practices)!
Glad too that it’s only the admin that is slow, not the record search and display themselves.
If there’s no other sensible alternative, then I should have the coding skills to port to v4 and perhaps figure out the performance issue, if not the in-depth OmekaS internals knowledge…
We’re running into the same issue with nested data when using CIDOC CRM in Omeka and have found no suitable alternative. Did you happen to find a solution?
We had managed to sucessfully install the module by removing the version constraint, but it caused issues after install, so it seems there are some additional changes needed to get it to work in Omeka 4 (and possibly fix the ORM issues as well?).
OK, today is the day I start working on this, I have 2 days in my schedule to make this work properly.
First thing I’ve noticed beside some slowness is that the Data Type dropdown in Resource Templates misses the “Nested” section title, which makes it hard to find and set-up!
Now that I’ve actually used this, I do find the user experience a bit poor. Having to know what properties to manually find and add from a long list seems a pain. Omeka’s incomplete ontology support doesn’t include what Properties are valid for each Class, so you get the full list from the Ontology to choose from. (I wonder if this is one source for the slowness if you have all of schema.org being loaded multiple times?).
I’m wondering if a more ‘structured’ approach is better, i.e. you define in the Resource Template what properties you want added (or have available to add) and that comes up as a temple in the edit page instead? That would suit my use case perfectly, but not sure about others?
Thinking about the pre-defined properties a bit, one option would be to have a config page for the module where you choose the Class and Properties you want as a nested Resource, that gets saved to some new tables, and the data type gets built from that in the edit page. But… that’s just effectively repeating the Resource Template concept? So perhaps the right answer is instead of choosing a nested Class and Properties to use, you choose instead a nested Resource Template that defines the Class and Properties to use? You could then have the full power of the correct widget and settings for each property. Now, there’s likely to be considerable technical issues in rendering that, but I might have a play with the idea at any rate.
OK, I’ve added a comment to the NestedDataTypes issue about the slowness highlighting what I think is the root cause of the slowness. Not an easy fix I suspect.
I’ve also submitted a pull request for the v4 support.
In the meantime, I’m still deep-diving the Omeka S docs and code to see if there’s a way to reuse Resource Templates instead, but my knowledge is shallow and the going is slow… If I can make it work, it will be a radical enough change in direction to be a new Module rather than a fix to NestedDataTypes.