Property:ContentODPDescription
From Odp
This property is of type Text.
This property is a subproperty of PatternSolution.
(previous 25) (next 25)
Pages using the property "ContentODPDescription"
Showing 25 pages using this property.
P | |
|---|---|
| Provenance + | Extracted core of PROV-O |
R | |
| RTMSmapping + | -- |
| Reaction + | This pattern defines a set of object properties to be used represent a sequence of events, generated by actions and producing some reactions. The usage should be focused on the object properties, leaving type relations to be inferred. |
| Reactor pattern + | The reactor pattern provides a building bl … The reactor pattern provides a building block for the ontological modelling of reactive processes. The pattern can be used across domains in scenarios where a reactor is used to run processes that consume inputs to produce outputs under controlled environmental conditions and when triggered by certain events. As an example, the pattern has been applied to the algal biomass domain to model the reactive process of algae cultivation. the reactive process of algae cultivation. |
| RecurrentEventSeries + | A recurrent event series is modelled as an … A recurrent event series is modelled as an intersection of a collection and a situation. Indeed, a recurrent event is seen as a collection, since it contains entities that share one or more common properties and are unified conceptually (unifying factors). These entities are member of the collection, and are all consecutive events. At the same time, a recurrent event is a situation, intended as a relational context in which the contextualised things are based on a frame: a recurrent event is similar to a plan that defines how the things involved in that plan (i.e. the specific events) shall be carried out, e.g. where the events shall be located, in which time of the year, etc. e located, in which time of the year, etc. |
| RecurrentSituationSeries + | A recurrent situation series is modelled a … A recurrent situation series is modelled as an intersection of a collection and a situation. Indeed, a recurrent situation series is seen as a collection, since it contains entities that share one or more common properties and are unified conceptually (unifying factors). These entities are member of the collection, and are all consecutive situations. At the same time, a recurrent situation series is a situation, intended as a relational context in which the contextualised things are based on a frame: a recurrent situation series is similar to a plan that defines how the things involved in that plan (i.e. the specific events) shall be carried out, e.g. where the situations shall be located, in which time of the year, etc. e located, in which time of the year, etc. |
| Region + | This pattern is a basic one, which allows to talk about attributes/parameters/dimensions, while still referring to their values. It creates a path from things to data values through 'regions' representing attributes. |
| RelativeRelationship + | Gypsum is cheaper to replace than brick. |
| ReportingEvent + | There are in total 3 different types of ev … There are in total 3 different types of events included in the pattern. The most important one is the ActualEvent, which is the physical event -- event that actually happened or is said to have happened. All the circumstances of the event (contexts) are not directly linked to the ActualEvent. They are attached to the ReportedEvent, which constitutes a view of the actual event included in a particular description/report/statement. By making the ReportedEvent an Event, we can use all properties that could be used in case of an ordinary event, like place, time interval, cause and consequences. They are grouped in a class ReportedEventContext and are attached by hasContext property or its specialisations. As ReportedEvent provides an information about the ActualEvent entity, it can be viewed as InformationObject. It is connected to an ActualEvent using the isAbout property. The third event included in our pattern is the act of reporting the actual event -- the ReportingEvent. Its result is an ReportedEvent (linked using property reports). By modelling the act of reporting as an event, we can expose its different circumstances, for example the timestamp at which the particular reporting took place. The ReportingEvent can be also viewed as an activity, performed by a certain agent (person or organisation) -- EventReporter, utilising defined sources. EventReporter, utilising defined sources. |
| ReportingNewsEvent + | The pattern extends the ReportingEvent pat … The pattern extends the ReportingEvent pattern by specifying the primary properties of the specialisation of the ReportingEvent class. The specialisation, NewsEventReportingEvent, denotes the act of providing a unit of information (ReportedNewsEvent) to the general public. The act utilises a certain Media (TV station, radio station, newspaper, website). A Media is owned by a certain SocialAgent - NewsProvider. This agent takes partial responsibility for the content provided, but its responsibility differs from the one of the NewsEventReporter -- an Agent that directly reports the ActualEvent. Other properties which are very important for NewsEventReportingEvent are time at which the event is reported and the context of presentation. reported and the context of presentation. |
| ResourceAbundanceObservation + | ... |
| ResourceExploitationObservation + | ... |
| Role task + | This pattern is basic, and is used to connect intensional descriptions of actions (tasks) and objects (roles). |
| Roles (OWL 2) + | Extend the[[Community:Social Reality (OWL … Extend the[[Community:Social Reality (OWL 2)|Social Reality (OWL 2)]] pattern with classes for roles, functions, agents and actions. Create a new subproperty "plays" for the counts-as relation. We create new property chains to traverse the context and plays relation, that allow us to infer the role-as-relation from the role-as-class description. Imports the[[Community:Social Reality (OWL 2)|Social Reality (OWL 2)]] pattern from [http://purl.org/net/social-reality]. from [http://purl.org/net/social-reality]. |
S | |
| Sequence + | This pattern is a basic one; it represents … This pattern is a basic one; it represents the 'path' cognitive schema, which underlies many different conceptualizations: spatial paths, time lines, event sequences, organizational hierarchies, graph paths, etc. Sequence pattern reuses the logical pattern [[Submissions:TransitiveReduction|Transitive reduction]], in order to represent both transitive and non-transitive precedence relations. e and non-transitive precedence relations. |
| Set + | A Set is a collection that cannot contain duplicate elements. A Set is expressed by linking to it directly all the members (elements), multiple identical values of members (elements) will be eliminated because by default they are treated as a set. |
| SimpleOrAggregated + | The class "ObjectByCardinality" has been c … The class "ObjectByCardinality" has been created to classify simple and aggregated objects into its subclasses "SimpleObject" and "AggregatedObject", respectively. These subclasses are disjoint among them. The aggregation relationship between objects means that objects can be composed by other objects. This relationship is represented by the transtive property "hasAggregatedMember" and its inverse "isAggregatedMemberOf". These properties have as subproperties the non transitive properties "hasDirectAggregatedMember" and its inverse "isDirectAggregatedMemberOf", respectively. By means of this structure of properties, we provide a mechanism (a) to represent transitive aggregation relationships (that is, if A has B as aggregated member and B has C as aggregated member then A has C as aggregated member) and (b) to link each aggregated member just to the next level (that is, A has B as direct aggregated member). Finally, the class "AggregatedObject" has been defined as equivalent to those things that have some values for the property "hasAggregatedMember". This modelling allows the automatic classification of aggregated objects in this class when a reasoner is applied. in this class when a reasoner is applied. |
| SimpleTopic + | --- |
| Situation + | - |
| Smart City Strategy Design + | Problem-Cause-Effect ODP is intended to mo … Problem-Cause-Effect ODP is intended to model a city problems and analyse them with their related causes and effects. Problem-solution-vision ODP defines a city vision. Next, missions and values related to the vision are defined using vision-mission-value ODP. Mission-Goal ODP allows to identify goals related to each mission. After identifying goals, objectives and strategies are identified and aligned to goals using Goal-Objective-Strategy ODP. For a formal design of strategies, Strategy ODP is used. Projects that implement each strategy are defined and scheduled using Project ODP. e defined and scheduled using Project ODP. |
| SmartHome + | The solution is based on importing 8 ontology modules and link them together via specializing their concepts. |
| SmartHome Event + | TBD |
| SmartHome FeatureOfInterest + | TBD |
| SmartHome Geometry + | TBD |
| SmartHome Network + | TBD |
