What is the correct representation for a timestamp?

[chrishargreaves]

I cannot find a representation for a timestamp?

I can find:
core:startTime
core:endTime

and then a load of very specific ones:
observable:timeDateStamp
observable:mftFileNameAccessedTime
....

but what is the representation for a timestamp from say a niche logfile that doesn't warrant creating it's own unique named property?

The start+end time reflects the reality of an event, but the raw data that is stored, is a single point not a range.

[ajnelson-nist]

There isn't currently an "Umbrella" way of representing a general timestamp, aside from using extension properties. There are a few ways to approach this:

1. The user/application defines their own property, http://example.org/ontology/myTimeStampProperty.
   • Pro: Maximum user flexibility.
   • Pro: Invents in a manner comfortable within general RDF modeling.
   • Con: Onus is on user to extend any other applications to recognize their own time property, or set up a translation mechanism to align their timestamp-literals with other UCO objects like uco-observable:EventRecord.
2. UCO sets up a general, "Top"-level time property, and specializes all current timestamp properties under this with rdfs:subPropertyOf.
   • Pro: Provides demonstration for users on how to define extension properties.
   • Pro: Assuming RDFS or OWL entailment (if not full entailment, at least rdfs:subPropertyOf expansion rules), relieves users from writing some extension properties.
   • Aside: Such a top property should be flexible enough to support multiple timestamp datatypes (xsd:dateTime, xsd:dateTimeStamp), but mechanisms exist to do this in OWL and SHACL.
   • Con: While subclasses are supported transparently in SHACL, subproperties are not. So, new properties under such a top property might need some acrobatics to support "Inheriting" review logic from the top.
3. UCO supplementally implements a strategy around reifying timestamp-literals as specializations of uco-observable:EventRecord.
   • Pro: This approach could simplify some application design questions around timeline implementation. General logic could be written around EventRecord.
   • Pro: Some modeling matters are more straightforward to address when done with classes, such as "I need to find all intrinsic and extrinsic file modification times for PDFs" leading to joining file system modification time records (NTFS has at least two), PDF-internal timestamps interpreted as record objects, digital signing times, unstructured text being interpreted as events that might have only partial time information (e.g., email messages describing when something was done).
   • Pro: Provenance of interpretation of a timestamp into a record can be recorded.
   • Con: This would add significant "Graph weight," as properties currently sitting as timestamp-literals would now have associated nodes.

I was hoping to explore option 3 after resolution of UCO Issue 651. Option 3 came up when I was discussing time modeling with another group, but I think needs significant demonstration of value the graph weight and potential class-hierarchy complexity.

[chrishargreaves]

Understood thanks.

The context, which I should have put in, was the addition of a fairly barebones "T1076: Log file examination" to SOLVE-IT, and trying to work out what CASE classes might come out of this technique.

SOLVE-IT-DF/solve-it#153

Currently have these as potential Digital Forensic Technique Results:

Log entry - observable:EventLog
Log entry timestamp - ?
Log entry type - core:eventType