simpler time format

[fosterlynn]

Trying to get the time formatting nailed down so I can get it properly into the graphql reference. This is in some of your examples @elf-pavlik but I'm not sure it is valid owl/rdf, assuming the time: is in the context? I hope so, I like it....

Other question: How would we do an instant? Would we just need both properties hasBeginning and hasEnd? Or can we get away with one or the other? Or would we need something different? I think you answered some of this somewhere, but I have looked and can't find it.

And one more: Is our rdfs:range still correct for this example? Like here:

vf:observedTime a           owl:ObjectProperty ;
        rdfs:label          "observed time" ;
        rdfs:domain         vf:EconomicEvent ;
        rdfs:range          time:TemporalEntity ;
        vs:term_status      "unstable" ;
        rdfs:comment        "The actual temporal instant or interval." .

[fosterlynn]

P.S. I'm thinking in our non-rdf implementations, we should settle on one way to do the times everywhere. In rdf, I assume people can pick and choose from the options in time:TemporalEntity? But we could settle on one representation in all the examples, which would tend to simplify it for people. Does this make sense?

[elf-pavlik]

Following changes to example we need to add in turtle file definitions for vf:hasBeginning and vf:hasEnd. We still will need a property for cases which need duration / temporal length.

[fosterlynn]

Following changes to example we need to add in turtle file definitions for vf:hasBeggining and vf:hasEnd.

I meant time:hasBeginnning and time:hasEnd. How would we best do that? Shouldn't we use time attributes? If we use VF attributes, why even define TemporalEntity? Or probably I'm not understanding something?

We still will need a property for cases which need duration / temporal length.

You mean that has a numeric value and a time unit? Not for our time attributes, right? But for the discussion of multiple quantities?

[elf-pavlik]

If we use time properties directly we would need to have this indirection

      time:hasEnd:
        '@type': time:Instant
        time:inXSDDateTimeStamp: 2018-10-15T18:00:00-0:00

In next comment I'll add ttl snippet which would define vf:hasBeginning and vf:hasEnd

[fosterlynn]

If we use time properties directly we would need to have this indirection

ah ok i understand - when you used them in examples, you meant vf:hasBeginning and vf:hasEnd

What are the trade-offs? What do you prefer?

[elf-pavlik]

vf:hasBeginning
  a owl:DatatypeProperty ;
  rdfs:domain time:TemporalEntity ;
  rdfs:range xsd:dateTimeStamp ;
  owl:propertyChainAxiom (time:hasBeginning time:inXSDDateTimeStamp) ;
  rdfs:comment "Specific time marking the beginning of the flow" .

vf:hasEnd
  a owl:DatatypeProperty ;
  rdfs:domain time:TemporalEntity ;
  rdfs:range xsd:dateTimeStamp ;
  owl:propertyChainAxiom (time:hasEnd time:inXSDDateTimeStamp) ;
  rdfs:comment "Specific time marking the end of the flow" .

What do you prefer?

I prefer #453 which follows how we had start and end defined on flows until recently.

How would we do an instant?

For the instant we can simply use time:inXSDDateTimeStamp directly on the flow, since we have case of time:Instant and not time:ProperInterval.

You mean that has a numeric value and a time unit? Not for our time attributes, right? But for the discussion of multiple quantities?

Yes I refer to cases where flows specify certain duration / temporal length, so distinct from the vf:has Beginning, vf:hasEnd and time:inXSDDateTimeStamp ( ~ at ) discussed above. In cases where one can record both the temporal length and beginning and end we could require that one includes both in the data (calculate it before publishing record) and not rely on application consuming data to calculate temporal length based beginning and end of the flow.

I will add to #471 which values I see playing roles for which requirements.

[fosterlynn]

So, vf:hasBeginning, vf:hasEnd, and time:inXSDDateTimeStamp would replace the current intendedTime, committedTime, observedTime in each flow, I assume? And people would use either (beginning and end) or the inXSDDateTimeStamp?

Is there any way to get something more conceptually named than inXSDDateTimeStamp? I think that would be somewhat important. Can we use hasTime in some way? (https://www.w3.org/TR/owl-time/#time:hasTime and also the end of 3.1 on that page) Or a vf: named property that works similarly to the way you defined vf:hasEnd and vf:hasBeginning? Then could we make it an Instant instead of a TemporalEntity or whatever is needed to just get it to have its own time:inXSDDateTimeStamp?

Even better, it would be good if we could make the beginning/end and the one instant into the same property on flows for simplification, and then branch underneath that? But this request is less important than the last one.

[fosterlynn]

Another point of discussion: Events seem pretty clear since they represent actuals. Commitments may need something like a "due date". Can we use just vf:hasEnd for that? Seems the most clear for this proposal, but I think you saw problems with that at some point?

[elf-pavlik]

Even better, it would be good if we could make the beginning/end and the one instant into the same property on flows for simplification, and then branch underneath that?

Actually I don't see any advantage in having such indirection.

Events seem pretty clear since they represent actuals. Commitments may need something like a "due date". Can we use just vf:hasEnd for that?

Looking at https://valueflo.ws/introduction/flows.html#commitment

Commitments describe potential future events which the involved agents already agreed to pursuit. Commitments can be considered contractual promises from one agent to another. Commitments are "mirrors" of economic events ...

Since we already have distinction between observed (or being observed) EconomicEvent and planned Commitment, we don't need different properties to capture that distinction. If everything goes as planned, the beginning and end on Event will exactly matched those on Commitment. If we need some other meaning than: event should begin at and start at we need to define different property for that or very likely we can rely on

So if we don't want to say that event should begin at and end at but rather event should end no later than, one could simply use time:intervalBefore or broader time:before. Using those clearly defined temporal relationships should allow people to clearly express what they need to express, including

• no later than (time:before)
• no earlier than (time:after
• sometime between (time:inside or time:intervalDuring)

etc.

[fosterlynn]

I guess this relates to our ongoing discussion of the quantities too in some way. A question of simplifying and supporting broader more flexible definitions vs a more complex model with more specifically defined properties.

Also, some of rdf just doesn't lend itself to other formats and technologies. I get that people can express pretty much whatever they want to in the owl:time ontology, which is great, and I like it, and it probably will be used when the semantic web is used, but we don't want that level of complexity in say the graphql reference.

And we need semantically helpful names. So basically a field called inXSDDateTimeStamp is a non-starter. XSD doesn't even exist for someone writing a graphql based api. We want to be expressing what is that particular time related to economic activity, imo.

Commitments are "mirrors" of economic events ...

This is a looser statement than you are interpreting it as. Sometimes commitments need to state a very exact time, sometimes they only need to state something like time:before. Depends on the level of coordination required. And there is never any guarantee that the event(s) will exactly reflect the commitment. Sometimes commitment times are time estimates.

So if we can't agree on one (or maybe two, one for duration and one for instant) time across the flow types, maybe we need to just define them differently. Commitment could be time:before and time:after maybe. Would that support all those cases?

[fosterlynn]

I've done a look through the owl spec https://www.w3.org/TR/owl-time/, and it looks to me like they are (properly) concerned with the intricacies of time definitions. Any semantic implications beyond that are up to the domain using owl:time. For example, there is no implication that a TemporalEntity, ProperInterval, or any interval representation implies that say some event has to be happening at all moments in that interval. It can just as easily be that 4 hours of work should happen this week.

This tells me that we can use them for broadly defined needs, with the agents doing the coordinating having an understanding of the exact meaning. Or we can define more fields with narrower domain definition. But both are valid using owl:time, and it is the domain semantic decision.

[fosterlynn]

btw, I like basing everything we use on the time:inXSDDateTimeStamp at the bottom, because that matches to the ISO1806 standard that the graphql people want to use - just we need meaningful names

[elf-pavlik]

A question of simplifying and supporting broader more flexible definitions vs a more complex model with more specifically defined properties.

I have impression that by saying 'more flexible' definitions you mean that different data publisher can use them meaning something different, which I see going against interoperability.

And we need semantically helpful names. So basically a field called inXSDDateTimeStamp is a non-starter. XSD doesn't even exist for someone writing a graphql based api. We want to be expressing what is that particular time related to economic activity, imo.

Since graphql api relies on context, one will most likely use JSON-LD which allows flexible mapping including defining aliases for using properties in inverse direction. GraphQL-LD also relies on such JSON-LD context.

btw, I like basing everything we use on the time:inXSDDateTimeStamp at the bottom, because that matches to the ISO1806 standard that the graphql people want to use - just we need meaningful names

turtle snippet in #470 (comment) uses property chain axiom to define property which relates temporal entity directly to XSD DateTimeStamp and skips the intermediate instance of an Instant.

So if we can't agree on one (or maybe two, one for duration and one for instant) time across the flow types, maybe we need to just define them differently. Commitment could be time:before and time:after maybe. Would that support all those cases?

I don't see why we should expect people to use either specific beginning and end on commitment or before, after. One commitment will most likely use one or the other but different commitments will use different precision, luckily we have well defined owl-time ontology available to handle all those cases.

As for duration I think we need to see how different requirements work with it. For precise scheduling we seem to need precise beginning and end. Some earlier stage of planning will rely on duration and topological temporal relations. Duration also will come in play for the social accounting requirement.

[fosterlynn]

I have impression that by saying 'more flexible' definitions you mean that different data publisher can use them meaning something different, which I see going against interoperability.

I don't think so. I think it will be interoperable to the extent it can be and needs to be for economic activity and analysis. There are infinite degrees of differences in definitions, we have just picked different points in the continuum. It is the art of modeling, and figuring out what degree of detail the map should have to be most usable.

Since graphql api relies on context, one will most likely use JSON-LD which allows flexible mapping including defining aliases for using properties in inverse direction. GraphQL-LD also relies on such JSON-LD context.

I don't think graphql will use json-ld in our existing projects for the near - medium future. It doesn't rely on a context for its understanding of the model. However, I'd like to experiment some time with Graphql-LD, when it seems like it will be useful. Which I expect to happen at some point.

There are people using json-schemas too, both in holochain and ssb VF.

turtle snippet in #470 (comment) uses property chain axiom to define property which relates temporal entity directly to XSD DateTimeStamp and skips the intermediate instance of an Instant.

Saw that 👍 why can't we do it for the instant time?

luckily we have well defined owl-time ontology available to handle all those cases.

Unluckily perhaps, many formats will not use rdf or owl. I can just go ahead and define it I suppose, but it would be good to have it match our rdf definitions as much as possible, at least one rdf choice.

So we still are pretty far apart philosophically it seems, or at least in our assessements of the best modeling definitions on the continuum for REA.

[elf-pavlik]

Unluckily perhaps, many formats will not use rdf or owl. I can just go ahead and define it I suppose, but it would be good to have it match our rdf definitions as much as possible, at least one rdf choice.

I think vf graphql could include JSON-LD context which will handle mapping between RDF terms and json strings some people may prefer. Applications relying on those json strings would just need to make sure that they compact data on input using that specific JSON-LD context, while applications more aware about RDF can choose to ignore that JSON-LD context and operate directly on terms from various vocabs.

why can't we do it for the instant time?

It already has xsd:dateTimeStamp as range, applications relying on json strings can always alias it in the context "occuredAt": {"@id": "time:inXSDDateTimeStamp", "@type": "xsd:DateTimeStamp"}. vf graphql JSON-LD context could include such definition but only subset of applications that use it would rely on it.

[fosterlynn]

@elf-pavlik re. vf:hasBeginning and vf:hasEnd, do you think it is important to match the owl time names? Or can we use something like vf:beginsAt, vf:endsAt or something more readable? And then vf:occursAt too?

And let's assume there will not be any graphql json-ld context for now. And forever for people who don't want to use json-ld.

[elf-pavlik]

And let's assume there will not be any graphql json-ld context for now. And forever for people who don't want to use json-ld.

This one seems related to #444 and we could try to deal with it there as we work on other things.

vf:hasBeginning and vf:hasEnd, do you think it is important to match the owl time names? Or can we use something like vf:beginsAt, vf:endsAt or something more readable? And then vf:occursAt too?

Since I would like to rely on OWL Time for all the topological temporal relationships I see it a middle ground to define property chain axiom in VF namespace which skips the intermediate instant (in most cases a blank node). This way people only need to remember I can use variant from VF namespace to reference date literal directly instead of in addition have to remember the slight difference in naming. I also currently don't see advantage in defining vf:occursAt. Using either JSON-LD context or any other aliasing method idiomatic for specific programming language, people can alias things in a way they find convenient. Though for open source dev pool JSON-LD context might come as a middle ground for common way of doing aliases.

[fosterlynn]

Since I would like to rely on OWL Time for all the topological temporal relationships I see it a middle ground to define property chain axiom in VF namespace which skips the intermediate instant (in most cases a blank node).

I would like to rely on owl time too. But you suggested defining vf names, so I just thought I would check to see if we could make them better. We would still use owl for the rest of it, as you defined in your snippets with propertyChainAxiom etc. But I don't care really a lot. So I can go with your call on vf:hasBeginning and vf:hasEnd.

But I do need a different name for the one-time property (the instant). Can't be the XSD one, has to have one more layer outside of that somehow. Not sure how to best do it and keep the owl time stuff intact so it will still work for all the temporal relationships and stuff that the owl spec provides.

I also currently don't see advantage in defining vf:occursAt. Using either JSON-LD context or any other aliasing method idiomatic for specific programming language, people can alias things in a way they find convenient.

The advantage is a semantically meaningful name. And I think we shouldn't force non-rdf people to do some aliasing or whatever, now there is no standard vocabulary. I'd really like to find something for this one that still keeps the owl time link intact.

[fosterlynn]

@elf-pavlik if you completely disagree with coming up with a semantically useable name for the time instant, can we do this? One property for the flows, called vf:hasTime. Range time:TemporalEntity. Then we document 2 possible ways to use it:

vf:hasTime
   @type:time:TemporalEntity
   time:hasBeginning:
   time:hasEnd:

vf:hasTime
  @type: time:Instant
   time:inXSDDateTimeStamp:

(excuse the lousy syntax)

Then for the non-rdf treatments, I would do something like vf:hasTime, then either one or two datetimestamps in the xsd / iso format. Somehow, not sure how. Probably can't create a TemporalEntity like I did with QuantityValue in graphql. Maybe just a list - if it has 2 times then it is the beginning and end, if it has 1 time, then it is the instant. And some textual explanation.

[elf-pavlik]

vf:hasTime you propose seems to remove all the benefits of #453 , for example: #446 (comment)

  - '@id': org:e4783bef-9006-490c-9c03-389272c7444c
    '@type': EconomicEvent
    action: work
    provider: https://alice.example/
    receiver: https://org.example/
    resourceClassifiedAs: https://www.wikidata.org/wiki/Q3064143 # facilitation 
    time:hasDuration:
      time:unitType: time:unitHour
      time:numericDuration: 21.5
    time:intervalDuring:
      skos:note: October 2018
      hasBeginning: 2018-10-01T0:00:00-5:00
      hasEnd: 2018-10-31T23:59:59-5:00

Using Topological Temporal Relations, on can easily position interval with duration 21.5 hours somewhere during October 2018. It doesn't specify exact beginning and end but takes advantage from relative positioning defined in owl-time. I see it much more confusing to have that indirection with blank node caused by proposed hasTime.

  - '@id': org:e4783bef-9006-490c-9c03-389272c7444c
    '@type': EconomicEvent
    action: work
    provider: https://alice.example/
    receiver: https://org.example/
    resourceClassifiedAs: https://www.wikidata.org/wiki/Q3064143 # facilitation 
    time:hasDuration:
      time:unitType: time:unitHour
      time:numericDuration: 21.5
    hasTime:
      time:intervalDuring:
        skos:note: October 2018
        hasBeginning: 2018-10-01T0:00:00-5:00
        hasEnd: 2018-10-31T23:59:59-5:00

Then for the non-rdf treatments, I would do something like vf:hasTime, then either one or two datetimestamps in the xsd / iso format.

As example above shows, sometimes we can expect timestamp of an instant or beginning and end timestamps of an interval. In some cases flow only has duration and relative positioning using topological temporal relations.

[fosterlynn]

    time:hasDuration:
      time:unitType: time:unitHour
      time:numericDuration: 21.5

Do you think this is more useful as a time element than a quantity element? I don't see any purpose of it as a time element in this use case. There is not need for any relative positioning is there.

    time:intervalDuring:
      skos:note: October 2018
      hasBeginning: 2018-10-01T0:00:00-5:00
      hasEnd: 2018-10-31T23:59:59-5:00

I'm very confused about how this can or should all be defined in the vf ttl, given your last suggestion of the property axiom chains. And confused about what are all the possible examples for our known use cases.

Can you please define the ttl for all the time elements that you would see required for commitments and events? A complete vf definition? Then I can maybe figure out if it can be workable for non-rdf implementations, without owl time to help out.

[elf-pavlik]

We need nothing more than snippet in comment above: #470 (comment)

Merging #453 would formalize it even further but even without it anyone can simply use topological temporal relations from owl-time on any flow and process.

If in this use case this quantity only matters for reciprocity purposes we can switch to use that use 4 3d printers for 2hours sometimes next week to illustrate pretty much the same functionality.

[fosterlynn]

We need nothing more than snippet in comment above: #470 (comment)

OK, I thought we needed to define the instant explicitly. Then wondering how do we do it in graphql or in the UML model? For when it is an instant? Or are you thinking we should re-create a piece of the owl time structure? We pretty much did that for qudt quantities.

[fosterlynn]

We need nothing more than snippet in comment above: #470 (comment)

OK, I thought we needed to define the instant explicitly. Then wondering how do we do it in graphql or in the UML model? For when it is an instant? Or are you thinking we should re-create a piece of the owl time structure? We pretty much did that for qudt quantities.

Never mind, I think I need to let this one go, I think I understand there is no need to define an instant since people can use whatever they want from the owl time spec in our implied subclass.

So I'll just define something in the non-rdf treatments, and just not worry about it. That would keep it simple in those, rather than trying to re-create something.

[elf-pavlik]

I think we can merge it after:

• adding snippet from simpler time format #470 (comment)
• removing all the intendedTime, commitedTime, observedTime definitions and extra level of indirection (nesting) they caused in examples
• adding https://www.w3.org/TR/owl-time/ to https://valueflo.ws/specification/external-terms.html

If you like I could do commit per to do in this PR or create alternative PR with all those changes

[fosterlynn]

If you like I could do commit per to do in this PR or create alternative PR with all those changes

OK, thanks. Or if you don't get to it, I'll give it a try, I probably have more extra time than you.

[fosterlynn]

I think this one is resolved for now with other PR, closing.