Properties

Definition

Property is the most fundamental and the most versatile relation in CASTEMO knowledge graphs which connects entities of different kinds. Properties is such a special type of relation that it is singled out and treated separately from other Relations.

Any property has:

1. an origin, i.e. the entity to which it is attached,
2. a property type, and
3. a property value.

Properties serve for modelling:

• Adjectives, adjectival expressions, and appositions (e.g., qualities and inter-entity relations).
  
• Adverbs and adverbial expressions (e.g., time, space, and manner of action).

CASTEMO knowledge graphs give priority to the data-collection perspective, and attempt at creating a general framework for modelling information in the textual resources. That's why it does not have predefined properties but allows coders to fill them during the data-collection dynamically.

Any entity can have any number of properties.

In CASTEMO knowledge graphs, it is always read with the verb "has".

E.g.:

O John's hat  - [has] - C colour - C black

P Anna - [has] - C son - P Peter

There are two kinds of properties, which have the same structure but differ in the context from which they are attached to entities.

In-statement Properties are attached to entities from within a Statement - i.e. they are attached to entities used as actants of a Statement (in the case of adjectival expressions and appositions) or actions (in the case of adverbial expressions). Thanks to the position of Statements in CASTEMO knowledge graphs, such Properties are included in a Territory hierarchy from which they stem, and usually accompanied with a Reference to the Resource which served for compiling a given Statement.

Meta-level Properties (or, in short, Metaproperties), are properties attached directlyglobally rather than contextually to an entityentity, byand wayrepresents general knowledge which applies to all uses of generalthe knowledge.entity independently from context. For instance:
P Martha Wood - PROP - C sex - C female

Sometimes, one level is not enough to model thea property. E.g., if Elizabeth II was Queen of the United Kingdom from 1952 to 2022, it is important to declare both the role and its temporal span, e.g. in the following way:

P Elizabeth II - PROP - C office - C Queen of the United Kingdom

PROP - C TRP yyyy-mm-dd: started exactly - V 1952
PROP - C TRP yyyy-mm-dd: ended exactly - V 2022

It is not Elizabeth who has this time span, but her rule as queen of the United Kingdom. Thus, CASTEMO knowledge graphs have second-level properties to be able to attach properties to properties, and they have third-order properties to attach properties to properties of properties.

Technical specification

Also,The fromdata the "programmer's view", is slightly misleading.  From a strictly technical sense, properties are direct attributesmodel of theCASTEMO entityknowledge (e.g. object Statement has property "label" (type string), which defines name or description).  How to deal with it?   A person needs to understand how the entity is defined in the code and that the "property" in DDM (=DISSINET Data Model) does not have a strict meaning from OOP programming.  From now on, I will call the OOP property concept "attribute". And word property I will reserve for DDM purposes.

E.g. an entity  (dog), has a property (color) with the value (brown) like in OOP, just properties in DDM  are dynamic.  In simple data modelling, we would predefine object (dog) through its class (Dog), in which we would define an attribute color. Each instance of the class would have the attribute color.  Just the values of that attribute could differ among the different instances (dogs).

In DDM an entity object has attribute "properties" (technically, the attribute name is props, see below), which is a holder for any number of small "property objects" (type-value pairs), la voila, properties.

For these dynamic properties, a predefined ontology of concept entities is used. All of the dynamically recorded properties bear either
                         1) type: Concept -> value: Concept  or
                         2) type: Concept -> value: Value
structure.
Where Concept is an entity of type concept and Value is an entity of type value.

To make it more confusing, in the GUI of inkVisitor, these dynamically created properties are called "Meta properties".  This is because the core DDM entity is Statement, which has properties like actant1, actant2 or action - properties defined on the level of these in-statement entities are called in-statement properties.

Metaproperties always are inherent GLOBAL attributes of an entity, not contextual - in-statement are CONTEXTUAL.

What is an entity and (meta)property and 2nd order (meta)property in DDM?

An entity in the DDM is foremost a data object  (defined by IEntity class) which has

• 1) direct attribute variables like "label" or "id", but it
• 2) also has array variables which can hold other objects. 
  • Among others, an entity has array attribute props, which holds "properties" in the DDM sense (these are two variable objects composed of type and value pair, e.g. type:"occupation", value:"historian", they are defined by IProp class). 
  • On these property objects can be hanged  0-to-many of "detailing" properties (2nd order properties)
    • E.g. property  type:"occupation", value:"historian", can be extended by a property object  with    type:"research-area", value:"middle-ages".

Let's unpack it.  The DDMgraphs is technically defined in the inkVisitorInkVisitor typescript *.ts  files, which directly correspond to the JSON structure of the collected data in the DDB1corresponding database.

Each entity (e.g.  Action) has its own ts file (e.g. action.ts); see the GitHub repository:

In the sense of object-oriented design,  each specific entity (e.g. location, person) inherits the definition of the IEntity interface, which is in the entity.ts file.  The IEntity is defined like this (screenshot from 16th January 2023):this:

Example: location entity "Argentina"

Let's have a location record (object) from the Guglielmites datasetentity with the label "Argentina".

In the inkVisitorInkVisitor GUI, the core entity is displayed like this:

...

In the inkVisitorInkVisitor GUI, the properties which hold its geospatial localisation are displayed like this:

There is one property record with type-value pair, i.e. Property Type "coordinates (lat; long)"type" (a conceptConcept entity, an entity object of type C, thiswhich is taken is from DDMthe predefined ontology) and the valueProperty Value, in this case a Value object with the string ofholding the coordinatedecimal "value".geographic coordinates.  OnTo this record hangs the 2nd orderfirst-level property recordis attached a second-level property defining  "localisation precision", of the stated coordinates, where both values of the type-value pair are filled with C entities. 

For deeper conceptual understanding, the JSON structure can be more revealing, this is a full entity display: 

ItThe entity has class "L", i.e. it is an entity of type "location", and it has direct attributes, like label with the value "Argentina" and array attributes like props.

It has one property object in the props attribute.  This object has a lot of non-intuitive attributes, but theThe main thinginformation is held in type and value attributes.  And this property object also has one 2nd-ordersecond-level property in the attribute children.

The property object is defined by the class IProp,  see prop.ts file.

2ndSecond-level order (meta)properties

TheIn the Argentina example above, the coordinates property record has one property object which extends the information.

This object is a normal instance of the IProp class.

This

Meaningmeans -that its primary information is in type and value attributes. These hold IPropSpec objects, which refer to two concept entities, e.g. here, "localisation precision" and  "precise".

ConclusionTBD:

The DDM gives priority to the data-collection perspective, it tries to create a general framework for modelling the information in the textual resources. That's why it does not have predefined properties but allows coders to fill them during the data-collection dynamically.

Issues with the terminology

Is the properties, metaproperties and 2nd order metaproperties actually good terminology?   

From a non-programmer data-collector perspective, possibly.   But anyone trying to understand the DDM needs to understand the properties of the statement entity (Tomas sleeps "at home"), i.e. entities like Person (e.g. Tomas) or Action (sleeps) or Location (at home in Brno Bohunice)  are entities, the property is that, what is not actant or action.   

While "extending information properties" about entities (e.g. geolocation of the home), which uses the dynamically recorded properties, (the DDM calls them meta properties), are completely different object structures.

They are not just meta; they are NOT entities, while in-statement properties ARE entities.

In-statement properties vs. meta-properties

In-statement are those which are DEFINED in the statement, they extend the heart of the statement : action or actant.  

Meta-properties are those which are defined on the entity itself.