http://creativecommons.org/licenses/by/3.0/
Megan Katsumi
Ontology to capture concepts related to activities.
November 6, 2017
Activity Ontology
icity-activity
Developed as part of the overall iCity ontology effort, the iCity-Activity ontology is designed to capture concepts related to activities.
Changes from previous version:
-imported revised ontology of change (iCity-Change).
-revised representation of activities, removed ActivityOccurrence class
-added beginOf and endOf properties
-added axioms for preconditionOf, effectOf, and achievedAt properties
Copyright @ 2016 Megan Katsumi, iCity Research Group
http://ontology.eil.utoronto.ca/icity/Activity/
1.2
Version 1. under development.
Please refer to report on iCity Ontology v1,
Also 2017 WOP Submssion "A Design Pattern for Representing Preconditions and Effects in OWL"
The WGS84 altitude of a SpatialThing (decimal meters
above the local reference ellipsoid).
altitude
The WGS84 latitude of a SpatialThing (decimal degrees).
latitude
The WGS84 longitude of a SpatialThing (decimal degrees).
longitude
nD Lat Lon
Added for organizational purposes, to identify all properties defined in the Activity ontology.
An activity occursBefore another if its endOf instant is before the beginOf instant of the other activity; the occursBefore relation is transitive. We cannot define this semantics in OWL, though it could be captured in future work by an extension with rules.
An activity occursDirectlyBefore another if it occursAt an interval that meets the interval of the other activity. We cannot define this semantics in OWL, though it could be captured by an extension with rules.
Added for organizational purposes to group properties defined in the Change Ontology.
Objects (e.g. perdurants and their manifestations) exist at some time interval or time point.
Created for organizational purposes, to identify the object properties imported by geoSPARQL.
Describes an approximate location of some object (spatial or non-spatial). For example, a Building has an actual location (represented by it's footprint or 3d massing), but it may also have an associated location(s) of some specific point coordinate. Recurring events may not have an actual location, but may be associated with some location (at which their occurrences are likely to occur).
A property intended to relate non-spatial objects (e.g. activities) to a location(s) in space.
Indicates that an object is a manifestationOf the sameTimeVaryingConcept as another object.
Created for organizational purposes, to identify data properties imported from geoSPARQL.
An Activity describes something that occurs in the domain.
An Activity may be further defined by (decomposed into) Subactivities.
An Activity may have precondition and/or effect State.
An Activity may be enabled by or cause some State. An enabling of causing state is a generalization of a precondition/effect; an Activity is enabled by or causes some State if it has a subactivity with a precondition or effect (respectively) of that State.
In other words, the state may not be required directly before, or cause directly after the activity, but by some more specialized sub-activity.
An Activity occurs at some point in time and space.
An Activity takes place during some interval, and so has some duration.
An Activity may have some Manifestations that participate in it.
Added for organizational purposes, to identify all classes defined in the Activity ontology.
Naturally, a conjunctive state type is defined by the conjunction of its child state types, whereas a disjunctive state type is defined by the disjunction of its child states.
Naturally, a conjunctive state type is defined by the conjunction of its child state types, whereas a disjunctive state type is defined by the disjunction of its child states.
2
A non-terminal state type has substates. It may be conjunctive or disjunctive.
A state type cannot be both conjunctive and disjunctive.
ConjunctiveStateType disjointWith DisjunctiveStateType
Conjunctive and disjunctive state types, which do have substates, are achieved at some time if their decomposition of state types is achieved.
Note that in this representation, decomp_of is not a transitive relation, it only refers to the direct children of a non-terminal state type. A more general relation that is transitive is the substate relation.
decomp_of(x,y) -> substate(x,y)
A state refers to a class of manifestations. It may be a precondition or effect of some Activity, or more generally it may enabled or be caused by some Activity. If a state is complex, it may refer to some combination of classes of manifestations.
A note on complex states:
Say that a shopping activity, Activity-Shop, requires both the VehicleW30LGas state, but also some state wherein the mall is open, OpenMall. Each state would first be defined separately. Then, we can simply state:
precondition(VehicleW30LGas,Activity-Shop) AND precondition(OpenMall,Activity-Shop)
were the preconditions required disjunctively, we could state:
precondition(VehicleW30LGas,Activity-Shop) OR precondition(OpenMall,Activity-Shop)
However, in large and complex domains, there will be cases in which the above approach is undesirable. In particular, due to the complexity of the description that results as the state being described becomes more detailed. In many cases it will be more natural and convenient to be able to refer to a single, aggregate state. We therefore extend the representation of States to capture aggregation, as approached in the concept of state trees introduced by TOVE as a construct for the activity cluster.
A State may be either non-terminal or terminal. A terminal state has no child states, and therefore refers directly to a class of manifestations, whereas a non-terminal state has child states, which may define some classes of manifestations, or further define some other complex states.
NonTerminalState(x) v TerminalState(x) = State(x)
A state cannot be both non-terminal and terminal.
TerminalState disjointWith NonTerminalState
0
A terminal state type has no substates (cannot be decomposed). It corresponds to a particular class of manifestations. A terminal state is achieved at some time if and only if there exists a manifestation within its defined classification, that exists at that time.
Added for organizational purposes to group the classes defined in the Change Ontology.
1
A Manifestation of some TimeVaryingConcept at a particular point/interval in time.
A Manifestation exists at some Instant.
The class of Manifestations is equivalent to the class of things that are manifestations of some TimeVaryingConcept - and only time varying concents - in the manifestationOf relation.
A class that is subject to change is defined as a type of TimeVaryingConcept (e.g. Vehicle may be a subclass of TimeVaryingConcept). The TimeVaryingConcept itself is invariant and defined by properties that do not change over time. As per (Krieger, 2008), we view TimeVaryingConcepts as perdurants (things that occur over time, i.e. processes).
A TimeVaryingConcept has Manifestations that demonstrate their changing (variant) properties over time.
Different types (subclasses) of TimeVaryingConcept may be defined based on the Manifestations that are part of them. For example, VehiclePD s have manifestations that are Vehicles.
A TimeVaryingConcept exists at some Interval.
The class of TimeVaryingConcepts is equivalent to the class of things that have some Manifestations - and only Manifestations - in the hasManifestation relation.
Created for organizational purposes, to identify the classes imported from geoSPARQL.
$Date: 2009/04/20 15:00:30 $
A vocabulary for representing latitude, longitude and
altitude information in the WGS84 geodetic reference datum.
Version $Id: wgs84_pos.rdf,v 1.22 2009/04/20 15:00:30 timbl Exp $. See http://www.w3.org/2003/01/geo/ for more details.
WGS84 Geo Positioning: an RDF vocabulary
Recent changes to this namespace:
$Log: wgs84_pos.rdf,v $
Revision 1.22 2009/04/20 15:00:30 timbl
Remove the time bits which have been deal with elsewhere eg in iCal.
Revision 1.21 2009/04/20 12:52:47 timbl
try again
Revision 1.20 2009/04/20 12:42:11 timbl
Add Event (edited ages ago and never checked in), and location (following discussion http://chatlogs.planetrdf.com/swig/2009-04-20#T12-36-09)
Revision 1.19 2009/04/20 12:36:31 timbl
Add Event (edited ages ago and never checked in), and location (following discussion http://chatlogs.planetrdf.com/swig/2009-04-20#T12-36-09)
Revision 1.18 2006/02/01 22:01:04 danbri
Clarified that lat and long are decimal degrees, and that alt is decimal metres about local reference ellipsoid
Revision 1.17 2004/02/06 17:38:12 danbri
Fixed a bad commit screwup
Revision 1.15 2003/04/19 11:24:08 danbri
Fixed the typo even more.
Revision 1.14 2003/04/19 11:16:56 danbri
fixed a typo
Revision 1.13 2003/02/19 22:27:27 connolly
relaxed domain constraints on lat/long/alt from Point to SpatialThing
Revision 1.12 2003/01/12 01:41:41 danbri
Trying local copy of XSLT doc.
Revision 1.11 2003/01/12 01:20:18 danbri
added a link to morten's xslt rdfs viewer.
Revision 1.10 2003/01/11 18:56:49 danbri
Removed datatype range from lat and long properties, since they would
have required each occurance of the property to mention the datatype.
Revision 1.9 2003/01/11 11:41:31 danbri
Another typo; repaired rdfs:Property to rdf:Property x4
Revision 1.8 2003/01/11 11:05:02 danbri
Added an rdfs:range for each lat/long/alt property,
http://www.w3.org/2001/XMLSchema#float
Revision 1.7 2003/01/10 20:25:16 danbri
Longer rdfs:comment for Point, trying to be Earth-centric and neutral about
coordinate system(s) at the same time. Feedback welcomed.
Revision 1.6 2003/01/10 20:18:30 danbri
Added CVS log comments into the RDF/XML as an rdfs:comment property of the
vocabulary. Note that this is not common practice (but seems both harmless
and potentially useful).
revision 1.5
date: 2003/01/10 20:14:31; author: danbri; state: Exp; lines: +16 -5
Updated schema:
Added a dc:date, added url for more info. Changed the rdfs:label of the
namespace from gp to geo. Added a class Point, set as the rdfs:domain of
each property. Added XML comment on the lat_long property suggesting that
we might not need it (based on #rdfig commentary from implementors).
revision 1.4
date: 2003/01/10 20:01:07; author: danbri; state: Exp; lines: +6 -5
Fixed typo; several rdfs:about attributes are now rdf:about. Thanks to MortenF in
#rdfig for catching this error.
revision 1.3
date: 2003/01/10 11:59:03; author: danbri; state: Exp; lines: +4 -3
fixed buglet in vocab, added more wgs links
revision 1.2
date: 2003/01/10 11:01:11; author: danbri; state: Exp; lines: +4 -4
Removed alt from the as-a-flat-string property, and switched from
space separated to comma separated.
revision 1.1
date: 2003/01/10 10:53:23; author: danbri; state: Exp;
basic geo vocab
geo
A comma-separated representation of a latitude, longitude coordinate.
lat/long