New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ODRL Temporal Profile TIME modelling is invalid + other suggestions #16
Comments
Thanks @nicholascar ! We will review and provide an update based on your suggestions. |
Hi @nicholascar - many thanks for your comments. Very useful! Take your point about Should Again, take your point about
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. |
You could declare a convenience property, equivalent to a TIME property chain that is something like This would not only avid an extra BN but include fewer than you original modelling... You might consider
Yes, oops! But you probably won't need 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 The advantages of this modelling are:
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 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. |
I am preferring the proposal from @nicholascar (above 20 jul) for temporal policies. |
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
|
In the ODRL Temporal Profile, some of the use of OWL-TIME is invalid. Example 1:
time:before
&time:after
are OWL Object Properties with range values oftime: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, adateTimeStamp
is used (includes 'Z') butdateTime
but it should actually just be adate
since no time value is given.I think what is meant is:
So here the
pProperInterval
indicated by theeffectiveDate
has a startingInstant
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
toeffectivePeriod
oreffectiveInterval
since the property is indicating aProperInterval
not adate
of any sort.Also, why do you need a
TemporalObject
class? This is just mirroring TIME'stime:TemporalEntity
but not adding any value (no distinguishing properties) and since you are making greate use of TIME, you should just directly useTemporalEntity
.I'm not even sure if you need
TemporalPolicy
since this could just be a standardodrl:Policy
with atime:hasTime
property indicating that it is temporal in nature.Taking this to the extreme, you might even get rid of
effectiveDate
and just usetime:hasTime
or, at the very least, makeeffectiveDate
(after renaming toeffectiveInterval
,effectivePeriod
etc.) asubPropertyOf
time:hasTime
.The text was updated successfully, but these errors were encountered: