[tmcl-wg] Functional Requirements and Syntax Proposals: Please Submit (Copy of message from Yahoo)

[Dmitry]

Just reposting my Yahoo group message...


[Mary Nishikawa]
>Here is an example. Please comment on structure and content. Thanks.
>-- Mary

>3.3 Classes (object-oriented) or Syntax Examples illustrating usage
>Scenarios in Functional Requirements Section 3.2

>We can use this section to clarify the context of the usage scenarios
>above. We may want to describe that the constraint may be described at the
>schema level or application level and use pseudo code for the application
>level descriptions.

I would like to provide some comments about item 3.3:
"Classes (object-oriented) or Syntax Examples illustrating usage Scenarios
in Functional Requirements Section 3.2".

My suggestion is to replace title with something like this:
"Examples illustrating Usage Scenarios on various levels of constraint
language"

When I look at these three items:

>Proposal 1  Syntax: XML DTD
>Source: Steve Pepper, Lars Marius Garshol; N0267 Ontopia Schema Language
>Specification Sections 2.7, 2.8, 2.9 Also see relvant sections in DTD.
>
>Proposal 2 Syntax: AsTma!
>Source: xxx
>
>Proposal 3: OOP pseudocode
>Source: xxx

I do not see them as alternative languages. I think that we have here one
sample for each layer of constraint infrastructure. I would like to suggest
renaming them this way:

Schema or Class Template layer

Sample 1: OSL.
Source: Steve Pepper, Lars Marius Garshol; N0267 Ontopia Schema Language
Specification Sections 2.7, 2.8, 2.9 Also see relevant sections in DTD.

Constraint Template layer

Sample 2: Constraint Template Language (CTL?)
Source: xxx

Constraint Expressions layer

Sample 3:  AsTma!
Source: xxx

The main idea of "Schema or Class template" layer is that we compress and
package basic constraints related to class  into one "schema document". No
additional search, no traversing "superclass-subclass" relationship,
everything "important" is in "schema document". Take it and use it (create
new instance in topic map editor, modify existing instance in editor, check
existing instance against class template, implement "smart" view with
demonstration of missing information.).


Example from OSL:

<topic id="composer" match="strict">
    <instanceOf>
        <subjectIndicatorRef href="http://psi.ontopia.net/opera/#composer"
/>
     </instanceOf>
    <otherClass>
        <subjectIndicatorRef href="http://psi.ontopia.net/opera/#librettist"
/>
    </otherClass>
<!-- some constraints -->
.
<!--  ROLES   -->
<!--  must play role of "person" in "born-in" association   -->

<playing min="1" max="1">
     <instanceOf>
        <subjectIndicatorRef href="http://psi.ontopia.net/opera/#person" />
     </instanceOf>
    <in>
        <instanceOf>
           <subjectIndicatorRef href="http://psi.ontopia.net/opera/#born-in"
/>
        </instanceOf>
    </in>
</playing>

<!-- some constraints -->
</topic>

Let's look at the same constraint:
["composer" must play role of "person" in "born-in" association .]
from "Constraint Expressions" perspective.

The main idea of "Constraint Expressions" layer is that we can use rich
language to express different types of constraints. Sorry, I can't provide
AsTma sample here but I will provide something close, I hope:

(forall $x (implies
                  (isa $x composer)
                  (existAtLeast $y  1
                       (and
                           (isa $y,born-in)
                           (playsRoleIn $x,person,$y)
                        )
                   )
                )
)

(forall $x (implies
                    (isa $x composer)
                    (existAtMost $y  1
                        (and
                               (isa $y,born-in)
                               (playsRoleIn $x,person,$y)
                        )
                    )
             )
)

(Actually, I am not sure that it is exactly the same statement as in OSL
sample, I hope it is close)

It is easy to add very complicated constraints which are out of scope of
"templates" at this layer. Probably, it is possible to interpret and check
"rich" constraints on specific set of instances (what do we do about
negation and "open world" assumption?). But I think this layer does not
really help topic map editors to create/modify topics. It can help mostly
with advanced validation. This is why we definitely need "Class templates"
and/or "Constraint Template" layers.

The main idea of "Constraint Template" layer is that we explicitly define
constraint templates (they are not the same as class templates!). And we
define specific constraints as instances of constraint templates. Each
constraint exists as separate entity. We can make statements about
constraints.

Example:

Constraint Template1:
[Each instance of class $P has to have at least $N associations of class $Y
in which this instance plays role of class $R]

Constraint Template2:
[Each instance of class $P has to have at most $N associations of class $Y
in which this instance plays role of class $R]

Constraints:

CS1:
[Each instance of class "composer" has to have at least "1" association of
class "born-in" in which this instance plays role of class "person"]

CS2:
[Each instance of class "composer" has to have at most "1" association of
class "born-in" in which this instance plays role of class "person"]

We can create "on the fly" class templates from template-based constraints
(and cache class templates somehow). We can even create class templates for
"temporary" classes. For example, if user specifies in topic map editor that
(isa john3000, perl-hacker) and (isa john3000,java-hacker) constraint engine
can create schema on the fly for "perl-hacker and java-hacker" class and
topic map editor will use it to get additional information from user about
john3000. We also can more or less easily implement "constraint propagation"
through class hierarchy.

 That is what I have so far...

Dmitry