There are some events that are easily detected. It is not hard
to tell when a firecracker has exploded. It is much harder to
find the bottom of a recession. It's all in the classifiers
or filters. (02)
An interesting question might be: how do we migrate from detecting
simple events to more complex ones. Or, we might discuss how those
events are represented in an ontology so that they are anticipated
and detected correctly. I am particularly interested in the linkage
between predicates and the metrics for detection. (03)
I just finished G.Lakoff's book on category theory, it is popular
writing but quite an interesting read, "Women, Fire and Dangerous
T: 978-505-9878 (05)
AzamatAbdoullaev wrote: (06)
> "events are primarily linguistic or cognitive in nature. That is, the world
> does not really contain events. Rather, events are the way by which agents
> classify certain useful and relevant patterns of change."
> I read many event ontologies, but this one is the most idiosyncratic, softly
> Wonder if it is in the Linked Data Cloud. If yes, then it hardly will give
> any refreshing rainwater.
> The world without events is the world without any precipitation as well :).
> Azamat Abdoullaev
> ----- Original Message -----
> From: "Toby Inkster" <tai@xxxxxxxxx>
> To: "Niklas Lindström" <lindstream@xxxxxxxxx>
> Cc: "Semantic Web" <semantic-web@xxxxxx>
> Sent: Wednesday, September 02, 2009 1:14 PM
> Subject: Re: Vocabularies for file data, content events, errors
> On 2 Sep 2009, at 10:37, Niklas Lindström wrote:
>>* simple file data properties, describing:
>> - checksum+algorithm (and/or direct properties for md5, sha1/-2 etc.),
>> - filename/slug (unless dct:identifier is suitable enough?).
> foaf:sha1 exists, but that might not be much use if you if you want
>>* content-related events, such as "the act of reading from a
>>dataset/collection (e.g. a feed)", "create", "update" and specifically
>>"delete" (or "deletion")
> ... track changes to the document's hash over time.
>>Currently we use AtomOwl to represent versioned entries
> That's probably a pretty good start.
> If you add in an events ontology (and I'd recommend starting with
> Yves Raimond's one and building on top of it) then you should be able
> to define a EntryChange class as a subclass of Yves' ev:Event class
> with accompanying previousVersion (subproperty of ev:factor) and
> subsequentVersion (subproperty of ev:product).
> Building on Yves' ontology for tracking document changes is more or
> less what I've done here:
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
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
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (08)