RASE are not referenced

[VladimirAlexiev]

The 4 RASE classes are defined, but not referenced anywhere: there are no incoming/outgoing properties. I think you need to implement the structure described in https://github.com/Accord-Project/bcrl/blob/main/RASE.md#nisbetfuturevirtualconstruction2008: each RASE can have multiple RASE (recursively), their logical connectives (evaluation logic) are implicit, and atomic RASE (that are not further broken down) are implemented by different kinds of checks (simple comparison, declarative rule, procedural rule, subjective/human judgement).

[VladimirAlexiev]

• @EdliraK "Will check it but as it stand is not clear what you mean. "
• I hope it's more clear now: you've defined RASE classes but they are not used

[beachtom]

What is there is fine as is for now - the hierarchical comes from the hasPart relationship a few options:

(1) perhaps we should have some form of restriction that something that is an Application/Exception etc... should also have another type (2) or we can mention the hasPart directly on the RASE item itself - (3) or make RASE items a subclass of one of the document structuring classes

[VladimirAlexiev]

Right, I've missed it since it's in different files (aec3po.ttl vs document.ttl):

• aec3po:Requirement < aec3po:Statement < aec3po:DocumentSubdivision
• aec3po:Document -dct:hasPart- aec3po:DocumentSubdivision

Then we don't need aec3po:hasSubCheck and aec3po:ChecklistStatement

should also have another type

Which other type do you mean?

[beachtom]

If the heirarchy is in place no other type needed in my view.

We need some way of distinguishing if something is inline or hierarchical. The way I do it at the moment is looking if it is a CheckListStatement

[VladimirAlexiev]

@beachtom Let me see if I understand you right by paraphrasing:

• "inline": atomic check (comparison, declarative, procedural, or human)
• "hierarchical": composite check (through RASE structure)

[beachtom]

OK so let's say

Hierarchical:

Doors should be all of:

• A
• B
• C

Inline

Doors should be A, B and C.

It is not important in processing but is important in presenting the text of the regulations back to the users in the form that they are familiar with

[VladimirAlexiev]

Ah! We shouldn't mix the kind of check (atomic vs composite) with the "verbalization" used in the regulation. The two above are the same, only stated slightly differently.

@EdliraK , @maximelefrancois86 , @beachtom

• "presenting the text of the regulations back to the users" is an important requirement
• so in my example https://github.com/Accord-Project/bcrl/blob/main/FI-accessibility-numbered-titled.txt I've been careful to keep the original wording and flow of text
• (things in parentheses are titleAdded, not part of the original text)
• So if you just concatenate all text fragments of all descendants of node X in order, you'll get the original text of X. Maxime, that's a good reason to keep hierarchical (global) identifiers: that way all descendants are ordered properly (in depth-first order).

Tom, the text of your examples can be broken up like this:

# FIRST
1.1 Doors should be all of:
1.1.1 - A
1.1.2 - B
1.1.3 - C

# SECOND
1.1 Doors should be 
1.1.1 A, 
1.1.2 B 
1.2.3 and C.

We could also store the full text of a node redundantly, but I think that's a worse choice.

In both cases the structure is the same (assuming A is a type check, B,C are a property check):

• identifier: 1.1, kind: composite, object: door, requirement:
  • identifier: 1.1.1, kind: atomic, type: A
  • identifier: 1.1.2, kind: atomic, property: B, comparator: ..., value: ...
  • identifier: 1.1.3, kind: atomic, property: C, comparator: ..., value: ...

IMPORTANT: the computation logic is determined by the relation from parent to child check, not by the type of child. Presumably, the same check can be a Requirement in one parent but an Exception in another parent. @EdliraK, what do you think?

[beachtom]

Taking a step back - from a user perspective as long as I can differentiate so how between the two then it is OK

[beachtom]

Looking at this now - I think this is fine as-is. Suggest this is closed