Dear Ed and All,
First, this area has been thoroughly studied, not to say that a good solution to most problems has been found. You might just look up “3D ontology” and “4D ontology” on Wikipedia or your favorite search engine, and see where it takes you. An accepted 3D ontology (which is approximately what your graphs model) is Nicola Guarino’s work on DOLCE (note the name!). Matthew West (a regular Ontolog contributor) and friends have been propounding a 4D ontology under the names EPISTLE and IDEAS. The 4D approach considers a thing in a different state to be a different ‘entity’, which is a ‘temporal part’ of a ‘whole life individual’. Some temporal parts have time stamps; others are simply known by the characteristics of their state. Which temporal parts are the same as others, or can be decomposed into parts that reflect multiple simultaneous states, is a largely unsolved problem (but the intended use may not care).
[MW>] You certainly need to have an identity basis of some sort (when are two things the same). Both ISO 15926 and IDEAS take two objects as the same if they have the same spatio-temporal extent. In practice, that means that two states are the same if they are states of the same object (same spatial extent) and they have the same start and end time/date (same spatial extent). Of course if you do not know start or end date/times for two states you may not be able to determine if they are the same or not – there is no magic.
General rule: Formal time modelers generally don’t agree on anything much. The ‘mathematical continuum with points in time’ model is only somewhat compatible with any algebraic interval model of time, and collides with the ‘branching futures’ models. A state holds for a time interval, and defines one. To put time points in that interval, you often have to put time points at the ends. Otherwise you are working with intervals of uncertainty (which is analogous to signal processing in being intrinsically statistical). By comparison, it is easier in formal logic to deal with intervals that don’t overlap and intervals that do/might overlap, however that may be determined, but you can’t necessarily draw useful conclusions if you don’t know the parameters of the overlap. There is no good model for all problems.
[MW>] The important thing to take from this is not that it is too difficult, but that you need to think about how time relates to the requirements you are trying to meet, and make sure you have a model that is fit for purpose. A particularly bad approach is to start with a current state model and then try to add change, history and time later.
Regards
Matthew West
Information Junction
Mobile: +44 750 3385279
Skype: dr.matthew.west
matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
http://www.informationjunction.co.uk/
https://www.matthew-west.org.uk/
This email originates from Information Junction Ltd. Registered in England and Wales No. 6632177.
Registered office: 8 Ennismore Close, Letchworth Garden City, Hertfordshire, SG6 2SU.
Software engineers are easily seduced by the ‘central database’ idea that you can timestamp change transactions with a single reference clock. Make that a network of information bases and you have to deal with time synchronization and propagation delay in order to make sense of the time labels, and then you have to deal with the fact that there is no mechanism assuring data integrity in overlapping distributed change transactions. There is inherent uncertainty in the system, and the question is (as you say) whether the rate of change is low enough relative to the uncertainty that your chances of getting a confused result from a transaction are statistically low.
Over many years, I have done real-time control, communications, and distributed databases, and I have been playing with ontologies for the last ten years. It has been an object lesson in “the more you know, the more you know you don’t know”. When it comes to time models, for me they have always been problem-specific. (I do plead guilty to having been a principal in the development of the OMG Date Time Vocabulary, which is at heart a time interval algebra. I don’t suggest it as a solution to anyone’s problem. It does provide a way of formalizing ‘regulation speak’ and ‘contract speak’, which was its primary intent.)
-Ed
You wrote: "RDF is a description language, and it corresponds to, space. Time is the changing notion, it corresponds to reading and writing and is quite hard to model in RDF alone.”
I’ve found that if you think of Time as an Entity Type, a specific instance in time can then be treated no differently than any other instance of any other Data Type. In other words, it can be treated as a Node in space. Unfortunately, there is no way to capture and/or map to continuous time, however, any Instance or Entity of any Data Type can be mapped to specific discrete instances in time, with specific semantic context. This is really no different than Discrete Signal Theory. For example:
Time “2014.08.19.22:30.07.52.EST” is related as “The Creation Time” for Data Record Instance “XYZ Version 1”
Time “2014.08.19.23:32.40.01.EST” is related as “The Modification Time” for Data Record Instance “XYZ Version 2”
Time “2014.08.19.23:55.12.11.EST” is related as “The Modification Time” for Data Record Instance “XYZ Version 3”
Data Record Instance “XYZ Version 1” is related as “A Version Of” Data Record “XYZ”
Data Record Instance “XYZ Version 2” is related as “A Version Of” Data Record “XYZ”
Data Record Instance “XYZ Version 3” is related as “A Version Of” Data Record “XYZ”
In this way, you can start to do things like get snapshot views in time of a Graph/Network that allows you to compare any one view of a Graph[Tx] against any other view of a Graph[Ty]. In this way, you can also see a Graph move and change through time (kind of like motion picture cards that show motion when flipped fast enough). The question becomes, how granular do you really want to make your Graph before data explodes and gets out of hand?
I’ve found that this works well with things that don’t change too often, like trying to track the evolution of an Enterprise (and its Assets). However, it doesn’t work too well when applied to massive transaction volume situations, like turning Securities Exchange Transactions into Graph representations (e.g. across all Exchanges, for all Securities, of all Security Types, at all Price Ticks, for all Buyers and Sellers, etc.).
--
Frank Guerino, Chairman
The International Foundation for Information Technology (IF4IT)
http://www.if4it.com
1.908.294.5191 (M)
On 20 August 2014 01:17, David Whitten <whitten@xxxxxxxxxx> wrote:
There is an interesting discussion re reasoning about Time and State
with REST interfaces
at this URL:
http://teddziuba.github.io/2014/08/18/the-s-in-rest/
as a teaser, the idea is that just because we get a reference to data
in the form of a URL, there is no guarantee that the data referenced
is unchanging. The example the article talks about is a product being
sold, and the URL returns the current price. But accounting systems
(especially when money has been spent) don't want to know the current
price, they want to know the price at the time the product was
purchased. And the tax at that time, etc.
So reasoning about information that is changing with time requires a
way to tie the information to a particular time. Which requires a lot
of internal information to be externalized so the consumer of the web
service can use the information in the way it needs to be used.
What does the group think?
Funnily enough I was just reading that article.
For this I think of Kant and the a priori forms of sensibility, space, time and causality.
RDF is a description language, and it corresponds to, space.
Time is the changing notion, it corresponds to reading and writing and is quite hard to model in RDF alone.
Logic seems to me to correspond to causality.
In Joyce's Ulysses he changes space into the visible, and time into the audible. It's almost like time and music are related.
So given this, I think that ontologies and description frameworks need not worry too much about time / state, it seems to be another layer ...
David Whitten
713-870-3834
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
_________________________________________________________________ Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/ Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/ Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx Shared Files: http://ontolog.cim3.net/file/ Community Wiki: http://ontolog.cim3.net/wiki/ To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J