Agenda

1. Notation
2. More data modeling

General principles

• We are trying to express a recursive hypergraph in a somewhat human-readable way.
• We will use a basic YAML-derived core: indented outline with initial symbols
• We will use some ideas from turtle: <global> identifiers and local identifiers as namespaced:curies
• We will also introduce a JSON-LD inspired idea of context.
• The data format “on the wire” will be quite different.

Asserted triple

- :Subject1
  * :Predicate1
    - :Object1

• The predicate is a binary relation, marked by the *.
• Subjects are introduced with -
• Local identifiers will probably be erased and converted to CIds.

Quoted triple

- :Subject1
  * :Predicate2
    o :Object2

The o marks quoting vs assertion.

In-line object

- :Subject1
  * eg:predicate1 : Object1
  o eg:predicate2 : Object2

You cannot inline multiple objects.

Asserted frame is a simple object

- :Frame1
  * @type : eg:frame_type
  * eg:role1
    - :Subject1
  * eg:role2
    - :Subject2
    - :Subject3

Note: I should always allow writing a binary predicate as a frame, so the triple can be used in object position.

Q: Should I distinguish full arrows from roles (half-arrows)? Eg <role1:frame_id:frame_type:role2>

Asserted frame inline

- :Subject1
  < eg:role1
    - :Frame1
      * @type
         - eg:frame_type
      * eg:role2
        - :Subject2

Using < for role back-reference.

Meta-statements

- :Subject1
  * eg:predicate1
    - :Object1
    * eg:predicate2
      - :Object2
    - Object3 {eg:predicate3 : Object4 , Object5 ; eg:P4 : O6}

Because it is at the same level, P2 applies to about the <S1,P1,P3> triple as a whole, not to O1 Note that order matters here. Inside {}: Pseudo-turtle notation, no nesting.

Statement identifiers and references

- :Subject1
  * eg:predicate1
    - :Object1
    * @id : :id_of_T1
    - :Object2 {@id : :id_of_T2}

Literals

- :Subject1
  * eg:lit_predicate1
    - "value"
    - "a:reference"
    * quoted
    - 34.4
    - true
      * a : Boolean

If it’s not a reference, or if it’s quoted, it’s a literal. Literals can be subjects.

Truth values

quoted and asserted is good enough for local. Not good enough for global truth. But {} notation might do for that.

Context

• Allow JSON-LD style context. All this should translate easily to RDF-* or JSON-LD*
• Local names are always to be translated to CIds. Global names are to be kept.

Relations (review 1)

• Fragments (Symbols in context) are interpreted as (immutable) ConceptRepresentations
• ConceptRepresentations can be declared equivalent
  • Concepts (subject proxy) as equivalence classes of ConceptRepresentations
  • Concepts are mutable. I am still unsure whether they should be materialized (probably, in which case there would be CIDs) and whether they have persistent identifiers. (Probably not.)

Relations (review 2)

• ConceptRepresentations are named using many Symbols
  • Definition: The set of ConceptRepresentations named by a Symbol is called the Symbol’s semantic scope.
  • Eventually: Distinguish denotational and connotative scopes
• In a Perspective, we can choose an unambiguous representative Symbol for a Concept
• Statements (complex concepts) reference Entities

Relations (review 3)

• ConceptsRepresentations are separated by Distinctions, joined by Abstraction
  • An Abstraction is thus materialized as a set of Distinctions.
  • The set should also note whether it is a complete cover of another ConceptRepresentation; then we have a ConceptCover, otherwise a ConceptUnion. We need better names for the cases where the cover is disjoint.

Relations (review 4)

• A distinct ConceptRepresentation may improve on an existing ConceptRepresentation
  • Improvements are meant to replace the original Concept (through its Representation)
  • An important special case is to replace an ambiguous Concept by a ConceptUnion. It is another form of interpretation.
  • If the concept is valid abstraction, we would instead add a ConceptCover in the equivalence class, based on one of the ConceptRepresentations in the class.

Relations (review 5)

• An equivalent ConceptRepresentations may clarify an existing ConceptRepresentation
  • Note: both the last two were called refinement in previous talks
  • It is tempting to say that distinction and improvement could act on Concepts. But I am still unsure whether to allow ConceptReferences.

Concept evolution

• ConceptRepresentations are immutable
• Concepts change in many cases:
  • An equivalence relation is added from a ConceptRepresentation in the equivalence class to a new ConceptRepresentation
  • The underlying concept is being replaced by a clearer version
  • A new distinction is introduced between two ConceptRepresentations that were previously deemed equivalent (i.e. the Concept is being replaced by a ConceptUnion)

Should we materialize Concepts?

More important: should Symbols refer to Concepts, or only ConceptReperesentations?

• Pro: If a Concept is being replaced by a ConceptUnion, we probably want to update back-references to the original Concept.
  • If we use a ConceptRepresentation, we have to recall equivalences at a point in time and update back-references to all other ConceptRepresentations equivalent at the time
    • This may not be harder than keeping the history of Concept forks, which we need in all cases.

Should we materialize Concepts? (2)

• Con: The equivalence relation is only deemed true locally to a perspective, so equivalence classes are perspective-local.

My current intuition is to not materialize Concepts.

Operations that do not take truth into account

• All Statements referring to any one ConceptReference
• All equivalence relation paths from a ConceptReference (yielding the broad equivalence class)
• All distinctions/improvements/clarifications pointing to/from any specific CR
• All distinctions/improvements/clarifications pointing to/from/both any CR in the Eq. class of a CR
• All Symbols which name a given CR (Or CR Eq. class)

None of those are expected to yield manageable sets…

Operations grounded in a point of view: truth

When rooted in a point of view, any relation has a (complex) truth value. We can start with a simplistic quaternary truth value and refine. (True, False, Unknown, Contested with fairly obvious semantics.) It becomes possible to note contradictions using rules on the subset of deemed-true relations. E.g.:

• two ConceptRepresentations cannot both be Equivalent and Distinct
• The true subset of improvements/clarifications should be acyclic
• A Symbol cannot be a Representation for two Distinct ConceptRepresentations

Operations grounded in a point of view: truth sets

In all those cases, the rules would also be applied to the non-false subset, to see if unknown or contested claims would introduce contradictions, in which case they can either the non-boolean values could be resolved as false, or all contradictory values could be considered contested. (I think both algorithms have independent merit.)

All the operations (two slides ago) should be computable on any of the truth-value subsets of the perspective.

Yes but how does it look like?

This is actually where I’m having issues. This defines many useful sets in a maximal way; but would a client application wanat to receive maximal sets of ConceptRepresentations and relations and sort it out? There are clearly benefits to defining more synthetic result sets. A first step is to make the sets smaller (according to some rules on next slide) but I feel there is more to it.

How would you want to receive the results to the specified queries?

Some result set reduction strategies

• clarifications form a partially ordered set within an equivalence class, it should be possible to only get the maxima (ie. no dominated ConceptRepresentation)
• Improvements form a partially ordered set between equivalence classes, it should be possible to get the maxima there as well.
• In the case of semantic scope, it would be preferable to get a single ConceptRepresentation per Equivalence class rather than the list of all of them. (Probably one of the maxima of the clarification relation.)

Appendix: Truth tables

Truth tables

| Or  | T | F | ? | ! |
+-----+---+---+---+---|
| T   | T | T | T | T |
| F   | T | F | ? | ! |
| ?   | T | ? | ? | ? |
| !   | T | ! | ? | ! |

| And | T | F | ? | ! |
+-----+---+---+---+---|
| T   | T | F | ? | ! |
| F   | F | F | F | F |
| ?   | ? | F | ? | ! |
| !   | ! | F | ! | ! |

| Not | T | F | ? | ! |
+-----+---+---+---+---|
|     | F | T | ? | ! |

Q: Supported by / opposed by? Different from causality?