Skip to main content

[draft] About properties, (meta)properties and 2nd order (meta)properties

Problem

The inkVisitor terminology can be confusing without initiation. One of the headaches comes from the specific conceptual architecture around "properties, metaproperties". 

Basic (confusion)

The GitHub readme.md says:

DDM in DDB1 work with entities of various entity types; these entities can have properties.

See https://github.com/DISSINET/InkVisitor readme.md.

Entity types

A Statement is an Entity type with the purpose of relating other Entities. All statements (as well as all other entities) have unique IDs, and their original order in the text is preserved, thereby allowing to follow the development of action in the narrative, the interplay of questions and answers, etc.

The other Entity types covered in the data model are:

  • Action type

  • Concept

  • Person

  • Group

  • Being (typically, animal)

  • (Physical) Object

  • Location

  • Event

  • Value

  • Text / Text part

  • Resource

Properties

Documentation on GitHub defines properties as

The uses of properties include:

  • Modelling 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 (=DISSINET Data Model) 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 - these are sometimes called in-statement properties.

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  a number 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:

image.png

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):

image.png

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:

image.png

...

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

image.png

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: 

image.png

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.

image.png

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

image.png

2nd order (meta)properties

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

image.png

This object is a normal instance of the IProp class.

image.png

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

Suggestion

Could we call entities in the statement actually in-statement entities? (These are from  some perspective properties of the statement, sure, but this bears advantage, we can get rid of the word "meta",  and all properties in a technical sense would actually object of the same type.

 



Back to top