Properties

Definition

Property

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

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

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

Sometimes, one level is not enough to model a 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

The data model of CASTEMO knowledge graphs is technically defined in the InkVisitor typescript *.ts  files, which directly correspond to the JSON structure of the collected data in the corresponding 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:

Example: location entity "Argentina"

Let's have a location entity with the label "Argentina".

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

...

In the InkVisitor 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)" (a Concept entity, an entity object of type C, which is taken is from the predefined ontology) and the Property Value, in this case a Value object with the string holding the decimal geographic coordinates.  To this first-level property is 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: 

The 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.  The main information is held in type and value attributes. And this property object also has one second-level property in the attribute children.

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

Second-level properties

In 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 means 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".

TBD: 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.