improve integration with OWL-Time

[elf-pavlik]

This reduces one level of indirection and duplication in the vocab. We can simply consider any Intent, Commitment and EconomicEvent as more specific time:TemporalEntity and use properties defined in Time Ontology in OWL directly one them. Since we already have distinct Intent, Commitment and EconomicEvent we don't need in addition observed*, commited* and intended* prefixes. One can simply check rdf:type (@type) of flow to have that knowledge.

Our examples already incorrectly use time:intervalEnds and time:intervalStarts (which have time:ProperInterval as range) we have to update them to time:hasBeggining and time:hasEnd (which have time:Instant as range). If we accept this PR, we can use those properties directly on any flow or Process.

[fosterlynn]

I agree we should fix the technicalities with our use of the owl:time spec. But I don't agree at all to make flows and Process subclasses of anything. I'm looking at the semantic side, not the rdf technicalities. I don't even think that times are all that critical on some flows - like say commitments that are part of a process and could just as easily imply their times from the process plannedTime. But in any case, Flows and Processes are not times, and are not that similar to each other. They have times. But the times mean different things.

[fosterlynn]

Since we already have distinct Intent, Commitment and EconomicEvent we don't need in addition observed*, commited* and intended* prefixes

I am however OK with trying to think of a name we can use for all of them for time (and quantities too).

[elf-pavlik]

like say commitments that are part of a process and could just as easily imply their times from the process plannedTime.

Time Ontology actually makes it quite straight forward:

'@id': ex:bb1388fa-57f9-4152-be33-31ac267cca4f
'@type': Process

'@id': ex:a35d58b1-5839-4d1b-a325-1c6d3f5d3d9d
'@type': Commitment
time:intervalDuring: ex:bb1388fa-57f9-4152-be33-31ac267cca4f

One can also state that one process needs to start after another one finished, or that process finishes when create event finishes etc.

[fosterlynn]

But fundamentally, subclass pretty universally means "is a" or like "is a type of". And Process and flow types are not TemporalEntities, that is such a small part of what they are semantically. We might even decide at some point there is a better time representation we want to use.

So to me, time is much better represented as properties of the classes we have, just like quantity, etc.

[elf-pavlik]

Relevant section from the spec which describes alignment with PROV: https://www.w3.org/TR/owl-time/#time-prov which has a lot in common with VF.

I find considering flows and processes as temporal entities very natural. This way one can also directly represent them on timeline (eg. schedule). Using Time Ontology we can express flows like:

'@id': ex:eb6b2521-8d46-4ef9-85fa-087585a56b73
'@type': Commitment
action: use
involves: ex:c9c8c652-f1a1-479d-a50b-05beaa9825ac
involvesQuantity:
  qudt:unit: unit:Number
  qudt:numericValue: 8
time:hasDuration:
  time:unitType: time:unitHour
  time:numericDuration: 2
time:intervalDuring:
  time:hasBeggining:
    time:inXSDDateTimeStamp: 2018-10-15T8:00:00-0:00
  time:hasEnd:
    time:inXSDDateTimeStamp: 2018-10-15T18:00:00-0:00

use 8 pcs for 2 hours on Oct 15 2018, between 8:00 and 18:00 UTC

[elf-pavlik]

also valid:

time:hasDurationDescription:
  time:hours: 2

but we should discourage it since other seems easier to compute.

I think the best for queries would come with:

'@id': ex:eb6b2521-8d46-4ef9-85fa-087585a56b73
'@type': Commitment
action: use
involves: ex:c9c8c652-f1a1-479d-a50b-05beaa9825ac
involvesQuantity:
  qudt:unit: unit:Number
  qudt:numericValue: 8
time:hasDuration:
  time:unitType: time:unitHour
  time:numericDuration: 2
time:intervalDuring:
  prov:endedAtTime: 2018-10-15T8:00:00-0:00
  prov:startedAtTime: 2018-10-15T18:00:00-0:00

Which removes indirection of time:inXSDDateTimeStamp

[fosterlynn]

This way one can also directly represent them on timeline (eg. schedule).

We can do that with time properties too. Can do everything we need to with time properties.

What would you do for non-rdf implementations? Still create a super-class? Seems very owl LOD specific. Seems OK to me to borrow LOD definitions for simple properties of VF classes, but not so much to inherit from non-VF classes, too fundamental to the model. (Besides my other main objection.)

time:intervalDuring:

I leave to you to pick the best for durations (and instants, not every flow time is an actual duration).

[elf-pavlik]

What would you do for non-rdf implementations? Still create a super-class? Seems very owl LOD specific.

I don't think time:TemporalEntity has to appear directly in any implementation.

Seems OK to me to borrow LOD definitions for simple properties of VF classes, but not so much to inherit from non-VF classes, too fundamental to the model.

We don't talk about any OOP inheritance, actually due to rdfs:domain and rdfs:range definitions as soon as someone uses time:intervalBefore with an instance of a flow, the reasoner can infer from that flow also has type time:ProperInterval.

Until recently we had directly start and duration property directly on flows: https://github.com/valueflows/valueflows/pull/291/files#diff-a5832671e1376b69e3b7f7fb50526009L342

I support reusing OWL-Time but I think we can do it in a way that we had before and just use properties from time: directly on flows as my snippets in comments above illustrate.

[fosterlynn]

I support reusing OWL-Time but I think we can do it in a way that we had before and just use properties from time: directly on flows as my snippets in comments above illustrate.

OK, so no subclassing I understand. 👍

I'll switch to your

time:intervalDuring:
  prov:endedAtTime: 2018-10-15T8:00:00-0:00
  prov:startedAtTime: 2018-10-15T18:00:00-0:00

That replaces this, right?

      '@type': time:ProperInterval
      time:intervalStarts:
        '@type': time:Instant
        time:inXSDDateTimeStamp: 2018-12-07T9:00:00-5:00
      time:intervalEnds:
        '@type': time:Instant
        time:inXSDDateTimeStamp: 2018-12-07T15:00:00-5:00

[fosterlynn]

time:intervalDuring:
  prov:endedAtTime: 2018-10-15T8:00:00-0:00
  prov:startedAtTime: 2018-10-15T18:00:00-0:00

Question: does this work also for intents and commitments? Or is prov assuming observed times? (The names imply observed times.)

[elf-pavlik]

Please wait with updating your examples, I think we can actually for this case define properties in vf: namespace and include OWL property chain axioms as in https://www.w3.org/TR/owl-time/#time-prov

also time:intervalDuring also comes useful only if you want to specify that one interval happens during another interval: https://www.w3.org/TR/owl-time/#time:intervalDuring

we don't need to if we just want to specify beginning and end of an interval we describe

[fosterlynn]

I still am not comfortable with the subclassing - the broad understanding of that term is like "is a", "is a type of", etc. And I think it is conceptually misleading.

[elf-pavlik]

It has very precise definition explaining exactly what it causes: https://www.w3.org/TR/rdf-schema/#ch_subclassof

I removed it for now since no need to argue about it in this PR

[fosterlynn]

That's a lot to expect apps to support. I think we should see what is used by known real use cases, and include them, then add as needed. After all, anyone can use any of them if they want, and have coordinated with their communication partners.

[elf-pavlik]

Any app only will support what functionality of that app requires. Here I don't consider server hosting some dataset as an app since it can't never know what various apps reading and writing from it will need or will not need and can't assume how many different properties apps will use. Still I only left those which we already encountered in our recent discussions.

[fosterlynn]

Not clear why you are calling out this particular unit? Even if true that we use it a lot.

[elf-pavlik]

Since we use it a lot people should know when to find it.