Preliminary rdflib resource for ISMI CIDOC-CRM time spans #117
Conversation
Based on @coderabbitai feedback
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
| @property | ||
| def label(self): | ||
| # for ISMI records, label is under the crm identifier/appelation | ||
| # other examples have it directly under the time span as RDFS.label |
There was a problem hiding this comment.
The idea is that the Time-Span is the processable Gregorian xsd:Date while the appellation represents the date in its original calendar therefore the appellation has the calendar type and its label has the date rendered in e.g. Hijri (the Time-Span label would rather have the date rendered in Gregorian)
There was a problem hiding this comment.
Thanks for clarifying, I sort of got what you were doing here but not fully.
How would this ideally map to an undate? Would it be two different undate objects? (they should sort the same). Or for this case would you ignore/bypass calendar conversion?
|
I think the pattern using the Appellation to represent the calendar is pretty generalizable. The problem is that there are no standard-URIs for the mini-ontology of calendar types and accuracy types. I currently use the ismi project namespace but to be really reusable the URI namespaces should be configurable. Maybe we could start with the ismi version and call the file and the class "cidoc_crm_ismidate" and generalize later? Or we leave it at "cidoc_crm" and add the configurability sooner? |
|
@robcast happy to follow whichever direction makes more sense to you here - I think either one works, and I don't have a clear sense of which would be easier. Would it be useful to create and publish our own namespaces for use with undate, or is it better to make it extensible so projects can use their own? Whichever direction we take, it would be great to talk through the approach and identify what classes and behaviors we want. |
@robcast I have preliminary work on an rdf resource class to map to your ISMI dates (related to #17). I called it
cidoc_ crmbut wonder if it should be made more explicit since it is particular to your implementation. (Hopefully in future we could generalize and make it more reusable.)I put it under converters but I'm not sure it can work the same as the other converters, since I think parsing and serializing both require the context of an rdf graph. I have only implemented and tested one case for the
to_undatemethod - I know you started on this in a notebook in another branch. I think ideally it should use the calendar-aware date parsing and then use the other fields to check/validate the conversion, but that probably requires merging in one of my other branches first... 😅LMK what you think about the approach, names, conversion, etc.