Clojurians Log v2

Maybe these could fit the purpose : https://www.dublincore.org/specifications/dublin-core/dcmi-terms/terms/issued/ , https://www.dublincore.org/specifications/dublin-core/dcmi-terms/terms/modified/ . We use them for tracking resources over time in one of the projects.

Thank you @kotlenik! yes, I think that’ll do. I had found dc:date, but that seemed too general to me.

how do you prefer to represent the dates? Just using ISO strings or used XSD Datetime?

leaning towards just using strings…

It made us a headaches often, so we stick always to typed literals using XSD datetime. But, if you have single store and fixed usage scenarios, you may use strings. But some day it may hurt you, so to speak.

Hmmm…

the issue I have with XSD Datetime is that it is too specific. I really just need a symbolic calendar date. It’s too bad this doesn’t seem to exist for RDF.

Timezones screw everything up

It is hard almost in every storage, because of a lot of formats people all over the world use. Not only timezones, but also the historic way people note dates. Eventually, you end up with wrapper around your store for data import making sure you have at your side unified approach. This is important if you have data coming from i.e. Asia, EU and US. It may differ significantly and is worth of effort to unify.

😕

There is xsd:date too, we tend to use this and xsd:dateTime for time literals

Oh, I never noticed that

Hmmm…. Jena seems to have a weird model-dependent relationship with datatypes https://jena.apache.org/documentation/notes/typed-literals.html

At least programmatically

I keep thinking about a reification scheme like this:

gregorian:2022\/12\/22 a gregorian:Date;
  rdfs:label "2022-12-22"^xsd:date;
  gregorian:duringYear gregorian:2022;
  gregorian:duringMonth gregorian:2022\/12;
  gregorian:weeklyRecurrenceOf gregorian:DayOfWeek\/Thursday;
  gregorian:monthyRecurrenceOf gregorian:DayOfMonth\/22;
  gregorian:annualRecurrenceOf gregorian:DayOfYear\/12\/22;
...
.

Come to think of it day of week might better be numbered, then labeled with "Thursday"@en

Using '-' instead of '\/' would probably be less hassle.

@eric.d.scott: yes http://reference.data.gov.uk until very recently ran a time uri service, which would generate things like that when dereferenced. It was particularly useful for things like “government years” etc. Unfortunately they sunsetted the service a few months ago, and a bunch of our gov clients use it, we’re hoping they’ll reinstate it on the original domain soon. Regardless the code that used to run it is here: https://github.com/epimorphics/IntervalServer

> Hmmm…. Jena seems to have a weird model-dependent relationship with datatypes https://jena.apache.org/documentation/notes/typed-literals.html @simongray what do you think is weird? The difference between lexical form and its entailment? Or not leaving datatypes open to ontology definition?

I would just have expected that I could do (XSDDate. "2022-12-22") or something similar since it seems perfectly able to independently consume that literal if it’s read in via an RDF dataset file.

So why is it suddenly tied to the model when doing it programmatically?

Makes no sense to me.

still not sure what you mean

The way I bootstrap my database is by generating a bunch of triples (represented as sets of vectors in Aristotle). I then add these triples to my database graph contained in an Apache Jena Model instance. However, if I want to add triples with XSDDate literals to my model I have to have access to the model in order to create those literals, which suddenly couples the model to those literals. It turns my neat one-way flow of bootstrapping into a directed acyclic graph since the data that is imported into the model (apparently) needs to be created in the model before it can be added to the model. However, if I consume a .ttl file with some XSDDates in it, I don’t need to know the model in advance. They are somehow able to exist independently while the ones I create programmatically are not.

I’m still not sure I follow 🙂 Though I don’t have as much experience with jena, so I could be missing something… but a model (as I understand it) is just an object / handle onto an in memory graph. createLiteral is essentially just a factory / constructor function for literals (which can presumably include dates). If you don’t want to couple it to the database model; then can you not just make a different one?!

It might just be a case of createLiteral being defined as an instance method when it should really be a static method.

Wait, there is also NodeFactory/createLiteral . Maybe the documtation is just misleading/out of date.

Well, in that case, there’s no issue it seems!

I agree it should really be a static method

Jena’s api’s are a bit weird in places; I’ve always found RDF4j to be much cleaner… though not quite as fully featured.

I’m deep in OWL land, so Jena was the best fit

Yeah RDF4j has a lot less support on that front