Re: [cti] Patterning Feedback -Timescales/Periodicity

[Eric Burger <Eric.Burger@georgetown.edu>]

inline

> On Oct 26, 2016, at 3:27 PM, John-Mark Gurney <jmg@newcontext.com> wrote:
> 
> Eric Burger wrote this message on Wed, Oct 26, 2016 at 14:55 -0400:
>> Proposal is that any time specification be in seconds with arbitrary precision and specification. Specification can be integer, floating point, or floating point scientific notation. Depending on the use of the, feel free to truncate or say “Sorry Dave, I cannot do that.” I.e., if I am sending you a CYBOX thingy saying the time between event A and event B is 3.44E-6 seconds, but you cannot distinguish anything less than microseconds, feel free to truncate to 3.0E-6. Or, if I am sending you a STIX thingy that says “look for an event that occurs precisely 7.64773828432385745010105868734202934508245094345845098 seconds, but you can only distinguish microseconds, we need to decide whether you need to be able to signal to the sender that you cannot accept that value, because it is way more than your precision, or you can silently truncate the value to the precision you care about.
> 
> I'll point out that the current specifications for that value does not
> require it to be an integer.

Nor do we want it to be.

> As to why it's human readable, is that humans are writing this, and it'll
> be a while before we have fancy UI's for writing patterns.

If that is the case, let’s go home. We are wasting our time. If humans are reading and writing it for human consumption in human timescales, the only thing we need to agree on is “use English” if you want international exchange (or pick some other Lingua Franca) and “use whatever you want” in a closed user group.

The whole *POINT* of the CTI effort is for machine digested and machine used interoperability. If the concern is there are no tools for it, I’m sure some university out there could be building open source tools, if the community wants it. [hint]

> IMO, the current specification is fine, maybe with the explicit addition
> that the x value may be a floating point.
> 
> I'm not sure everyone will know that the number of seconds in a year is
> 31536000.  (I had to calculate it myself.)

Thing one: you calculated it yourself rather quickly.
Thing two: feel free to say “1 year” to your tool. It will accurately calculate it as 31,536,000; 31,622,400; 31,557,600; or even know when to insert a leap second (yes, there are those, too, which are different than leap years). In fact, 31,557,600 might be seen as more accurate, as what is a year, anyway?

> 
>>> On Oct 26, 2016, at 2:29 PM, Bret Jordan (CS) <Bret_Jordan@symantec.com> wrote:
>>> 
>>> This really begs the question, and I am sorry in advance, but did we get our timestamp and timestamp-precision stuff all wrong????  If so, we should really fix that now. The dynamics of the community that put us down this path have changed.
>>> 
>>> So Eric, as our resident current academic, what would like propose we do here?
>>> 
>>> Bret
>>> From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Eric Burger <Eric.Burger@georgetown.edu>
>>> Sent: Wednesday, October 26, 2016 10:47:35 AM
>>> To: cti@lists.oasis-open.org
>>> Subject: Re: [cti] Patterning Feedback -Timescales/Periodicity
>>> 
>>> Upon reflection, I have convinced myself the only unit should be seconds, with no specified precision.
>>> 
>>> Yes, the examples given are nice and SQL-like and human readable.
>>> 
>>> I would offer that examples with those nice, human readable decadal time units are thoroughly unrelated and of near zero value towards a MVP. Why? Because that nice, human readable format, either as specifying patterns or for displaying what was detect, is a role of the user interface software. It is not a role of the data format.
>>> 
>>> One and only one data format specification: seconds.
>>> 
>>> Allow integer, floating point, and scientific notation.
>>> 
>>> We are totally done - interoperability guaranteed or your money back.
>>> 
>>> For those who want to display or enter pattern in seconds, milliseconds, femtoseconds, jiffies (3E-4s), moments (90s), or millifortnights (~1210s)* will be happy. They can do whatever they want, without having to convince everyone to adopt those time units in the language.
>>> 
>>> 
>>> 
>>> * Yes, there is an IETF RFC that uses millifortnights as a time unit.
>>> 
>>> 
>>>

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail