Properties

Properties

Documentation on GitHub definesattach properties as

The usesproperties of properties include:properties.

• Modelling

  Technical adjectives concerning actants.

• Instantiating Entities to parent types.
• Defining time and place of action (including in fuzzy terms).
• Recording other adverbials, for example, those concerning the manner of action, circumstances, causes or consequences of an action.

This is probably not helping much.

Also, from the "programmer's view", is slightly misleading.  From a strictly technical sense, properties are direct attributes of the entity (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.

Generally, the term "property" in DDM actually has its ontological "has a property"  meaning. 

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 DDM is technically defined in the inkVisitor typescript *.ts  files, which directly correspond to the JSON structure of the collected data in the DDB1 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):

Example: location entity "Argentina"

Let's have a location record (object) from the Guglielmites dataset 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. coordinates "type" (a concept entity, an entity object of type C, this is from DDM predefined ontology) and value object with the string of the coordinate "value".  On this record hangs the 2nd order property record defining  "localisation precision", 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: 

It 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 the main thing is held in type and value attributes.  And this property object also has one 2nd-order property in the attribute children.

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

2nd order (meta)properties

The coordinates property record has one property object which extends the information.

This object is a normal instance of the IProp class.

Meaning - 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".

Conclusion 

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 vsvs. meta-properties?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.