ODRL Temporal Profile TIME modelling is invalid + other suggestions

[nicholascar]

In the ODRL Temporal Profile, some of the use of OWL-TIME is invalid. Example 1:

[] a tpl:TemporalAgreement ;
    tpl:version  :T1-V1 , :T1-V2 . 

:T1-V1  a  odrl:Agreement ;
    tpl:effectiveDate [
        a time:ProperInterval ;
        time:before   "2020-01-01T00:00:00Z"^^xsd:dateTime
    ] ;
    tpl:temporalPermission :P1 . 

:T1-V2  a odrl:Agreement ;
    tpl:effectiveDate [
        a time:ProperInterval ;
        time:after   "2020-01-01T00:00:00Z"^^xsd:dateTime
    ] ;
   tpl:temporalPermission :P1 , :P2 .

time:before & time:after are OWL Object Properties with range values of time:TemporalEntity, so triples like :T1-V1 time:before "2020-01-01T00:00:00Z"^^xsd:dateTime in the above won't work since the property is indicating a Datatype object. Also, a dateTimeStamp is used (includes 'Z') but dateTime but it should actually just be a date since no time value is given.

I think what is meant is:

    tpl:effectiveDate [
        a time:ProperInterval ;
        time:hasStart [
               a time:Instant ;
               time:inXSDDate "2020-01-01"^^xsd:dateTime ;
        ] ;
    ] ;

So here the pProperInterval indicated by the effectiveDate has a starting Instant whose XSD representation is given. Of course, in practice, you could just do this:

    tpl:effectiveDate [
        time:hasStart [
               time:inXSDDate "2020-01-01"^^xsd:dateTime ;
        ] ;
    ] ;

Remove class indicators.

Suggestions

Looking over the example though, I suggest renaming effectiveDate to effectivePeriod or effectiveInterval since the property is indicating a ProperInterval not a date of any sort.

Also, why do you need a TemporalObject class? This is just mirroring TIME's time:TemporalEntity but not adding any value (no distinguishing properties) and since you are making greate use of TIME, you should just directly use TemporalEntity.

I'm not even sure if you need TemporalPolicy since this could just be a standard odrl:Policy with a time:hasTime property indicating that it is temporal in nature.

Taking this to the extreme, you might even get rid of effectiveDate and just use time:hasTime or, at the very least, make effectiveDate (after renaming to effectiveInterval, effectivePeriod etc.) a subPropertyOf time:hasTime.

[riannella]

Thanks @nicholascar ! We will review and provide an update based on your suggestions.

[benedictDD]

Hi @nicholascar - many thanks for your comments. Very useful!

Take your point about time:after/before. I also prefer effectiveInterval to effectiveDate. Will update. Sigh ... another blank node

Should time:hasStart be time:hasBeginning?

Again, take your point about tpl:TemporalObject vs. time:TemporalEntity. But I think I prefer the former for two reasons:

1. It has one job only: to hold the temporal versions of itself with the tpl:version property.
2. It provides a nod to developers already frustrated at having to work with an ontology, let alone one as complex as the time ontology, to the underlying software pattern we're using: Temporal Object.

Why is this pattern attractive? Because we want a stable identifier for (temporal) policies, permissions, and assets over time even as they are versioned. Why? Because once we start sharing these identifiers with inventory systems, access control systems, billing systems, identity management systems ... and on ... we don't have a lot of latitude to change them even as the underlying licenses change (which they do, regularly, in small detail).

I hope this clarifies the objectives of the profile.

[nicholascar]

Take your point about time:after/before.

You could declare a convenience property, equivalent to a TIME property chain that is something like tpl:effectiveBefore == time:hasTime/time:before/time:inXSDDateStamp and similar for tpl:effectiveAfter. Or tpl:effectiveUntil/tpl:effectiveFrom.

This would not only avid an extra BN but include fewer than you original modelling...

You might consider tpl:effectiveDuringInterval -> time:ProperInterval but a pair of tpl:effectiveFrom & tpl:effectiveUntil will cover it too.

Should time:hasStart be time:hasBeginning?

Yes, oops! But you probably won't need time:hasBeginning, given the suggestion above.

---

You might further consider if you could reuse other versioning semantics instead of your custom temporal ones, for example PAV. As per PAV, invoking Dublin Core, you could have an odrl:Agreement that has any number of dcterms:hasVersion properties indicating versions of it that differ in some way - permission changes, etc. - with the above properties indicating temporarily. The targets of the dcterms:hasVersion properties are also just odrl:Agreement instances linked back to the "master" with dcterms:isVersionOf if necessary.

The advantages of this modelling are:

• use of a standard version control modelling paradigm
  • in general this caters for temporarily but also for parallel versions (branching): likely not applicable here
• very common properties - Dublin Core
• no additional classes
  • you just look at an odrl:Agreement and, if it has versions, they are likely to be, or perhaps must be in ODRL's case, split temporally and you can do normal time sequencing form there with the tpl:effectiveUntil/tpl:effectiveFrom etc.

I really do think you could cater for your profile's needs without any special classes and only a few properties, so the profile would really just need to write up expectations: "if you want to create a temporally changing odrl:Agreement, indicate it's changed versions over time withdcterms:hasVersion..." and similar for any other thing changing.

This kind of temporal versioning with PAV common and present in major semantic collections, for instance changed Concepts in vocab systems like the NERC Vocab Server, see http://vocab.nerc.ac.uk/collection/P07/current/IY8BCT2K/3/. There you see a specific version of a Concept linked to other versions. They haven't reveled the temporal info - they don't really care to - but they are minting URIs for each version so people can quote the Concept version URI or the "head" (version-independent) one.

[riannella]

I am preferring the proposal from @nicholascar (above 20 jul) for temporal policies. It seems "simpler" and does not require new (container) classes to be defined. And the re-use of DC properties fits into the current ODRL Metadata direction.

[DavidFatDavidF]

As discussed a few times in the CG meetings (last time today 2021-12-06), I am in favor of the "simpler" model.. The advantages being

• the pattern of an always denoting stable URI is familiar, used in document management across open standards consortia for decades
• the ontologically richer pattern identifies a container object (new type of object so a breaking change or forwards compatibility problem when extending the core "timeless" ODRL) and the actual policy version is identified only in the second step even in the simplest case of the current version