Hi TMCL-WG Subscribers,

The Yahoo TMCL-WG mail list is being moved to isotopicmaps.org. You
will be receiving an invitation to join the list there soon.

You will no longer be able to post to the Yahoo group list from
tomorrow, but the archives will remain at Yahoo for some time.

Thank you for your patience.

Best regards,

Graham Moore and Mary Nishikawa

[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

Here is an example. Please comment on structure and content. Thanks.
-- Mary


3.2 Functional Requirements

Functional Requirement SP No. 1: Define Topics Used as Association Role
Types with their Classes

(Best title for this?)

Source: Steve Pepper (N 226 Section 3.1)

(Question: This is quite complex. Do we need to break up this into separate
functional requirements?)

Criticality: "MUST HAVE"

Definition: The TMCL must be able to define which topics are used for
association role types and the permitted classes of these role-playing
topics.  Cardinality may be expressed. Data typing is not. Validity in
scope may be expressed. The TMCL may define more complex constraining of
association role type topics with their classes. (Please comment on this)

(Note: This was rewritten to fit this format.  Please review and correct)

Information flow (how is the information flowing between parts?) Not
defined. Do we need this and if so, how would it be written?

Process Description (source: N226 section 3.1)

Usage Scenario 1: Constrain the topic "T" to be used for typing
associations and nothing else.

Example: The topic "born in" defines a class of associations.

Usage Scenario 2: Constrain associations of type "T" to consist of N roles,
"R1", "R2", ... "Rn".

Example: Associations of type "born in" must have two roles, "person" and
"place".

Usage Scanario 3: Constrain the role "R" in an association of a given type
to be played by exactly one topic belonging to the class "C".

Example: The roles "person" and "place" in an association of type "born in"
must each be played by exactly one topic belonging to the classes "person"
and "place", respectively.

Usage Scanario 4: Constrain the role "R" in an association of a given type
to be played by one or more topics belonging to the class "C".

Example: The role "project" in an association of type "project membership"
must be played by a topic of type "project", and the role "project member"
must be played by one or more topics of type "employee".

Usage Scanario 5: Constrain associations of type "T", such that

if role "R1" is played by a topic of type A1, then role "R2" must be played
by a topic of type "A2", "A2'", or "A2''";
if role "R1" is played by a topic of type B1, then role "R2" must be played
by a topic of type "B2", "B2'", or "B2''";
Example: Associations of type "located in" consist of two roles,
"container" and "containee" such that the "container" may be

¡¦         a topic of type "country", in which case the "containee" must
be
of type "state", "county", or "city";

¡¦         a topic of type "state", in which case the "containee" must be
of type "county" or "city";

¡¦         a topic of type "county", in which case the "containee" must be
of type "city";

¡¦         a topic of type "city", in which case the "containee" must be
of
type "theatre";

Usage Scenario 6: Constrain associations of type "T" to be in the scope "S".

Example: Associations of type "born in" must be in the scope "biography".


Data Constructs:  N/A

Data Dictionary:  N/A


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.

Functional Requirement No. 1 Define Topics Used as Association Role Types
with their Classes

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


---------------------------------------
Original Content from N 226 for your reference
---------------------------------------
3. Catalog of typical constraints
This section lists some typical ways in which designers might want to
constrain topic maps. The constraints are grouped according to the types of
topic map objects. The catalog is intended to provide a means whereby
different proposals might be evaluated. It is not complete and suggestions
are invited for other constraints that might be useful.

3.1 By association type
permitted association role types and cardinalities
permitted classes of role playing topics
valid combinations of the above
valid scopes
Example 1.1: Constrain the topic "T" to be used for typing associations and
nothing else.

Example: The topic "born in" defines a class of associations.

Example 1.2: Constrain associations of type "T" to consist of N roles,
"R1", "R2", ... "Rn".

Example: Associations of type "born in" must have two roles, "person" and
"place".

Example 1.3: Constrain the role "R" in an association of a given type to be
played by exactly one topic belonging to the class "C".

Example: The roles "person" and "place" in an association of type "born in"
must each be played by exactly one topic belonging to the classes "person"
and "place", respectively.

Example 1.4: Constrain the role "R" in an association of a given type to be
played by one or more topics belonging to the class "C".

Example: The role "project" in an association of type "project membership"
must be played by a topic of type "project", and the role "project member"
must be played by one or more topics of type "employee".

Example 1.5: Constrain associations of type "T", such that

if role "R1" is played by a topic of type A1, then role "R2" must be played
by a topic of type "A2", "A2'", or "A2''";
if role "R1" is played by a topic of type B1, then role "R2" must be played
by a topic of type "B2", "B2'", or "B2''";
etc.
Example: Associations of type "located in" consist of two roles,
"container" and "containee" such that the "container" may be

a topic of type (or supertype) "country", in which case the "containee"
must be of type (or supertype) "state", "county", or "city";
a topic of type (or supertype) "state", in which case the "containee" must
be of type (or supertype) "county" or "city";
a topic of type (or supertype) "county", in which case the "containee" must
be of type (or supertype) "city";
a topic of type (or supertype) "city", in which case the "containee" must
be of type (or supertype) "theatre";
Example 1.6: Constrain associations of type "T" to be in the scope "S".

Example: Associations of type "born in" must be in the scope "biography".

Hi,

We got through reviewing section 1 of N 226. Thank you for your help. I was
able to begin a first draft with your comments.

I would like to continue reviewing the contents of N 226 and see what we
should include, update or delete.

I am skipping Section 2 Definitions for now. Once we see the terminology
that is being used, I will add the definitions later on.

I would like to begin collecting functional requirements from you. I use
some of the content of section 3.1 N226 as an example which is in the next
mail from me.  Please comment on the contents as well as the structure.

If you would like to submit a requirement, please use the same structure,
and post it in a separate thread like this:
(see the my following post for an example.

-- Mary

-------------------------------

FR RB No. 1 (title of mail post)

Functional Requirement RB No. 1

Source: Robert Barta

Criticality: "MUST,"  "MUST NOT,"  "REQUIRED,"  "SHALL,"  "SHALL NOT,"
"SHOULD,"  "SHOULD NOT,"  "RECOMMEND," "MAY," and "OPTIONAL (select one)

Definition: (Give a brief sdescription of the requirement here)

Information flow:  (how is the information flowing between parts?)

Process Description:  (usage scenario)

Data Constructs:  if any (data types, arrays, class fields, etc.)

Data Dictionary: If any (A list of all data items in the function. Should
at least have name and data type -- short explanation, life span acuracy,
which functions or processes the data is used in.)

-------------------------------------

I've now, finally, gone through the votes and the result is:

   isotopicmaps  9
   XMLhack       7

So there is a majority for isotopicmaps, if not exactly overwhelming.

We will do the move as soon as possible. Details on what *you* need to
do will follow as soon as we have them.


   Who               What          Where
   ----------------- ----------------------------
   Kal Ahmed         XMLhack       tm?l-wg
   Holger Rath       XMLhack       tm?l-wg
   Mary Nishikawa    XMLhack       tm?l-wg
   Tony Coates       XMLhack       tm?l-wg
   Sam Hunting       isotopicmaps  sc34wg3
   Jim Mason         isotopicmaps  sc34wg3
   me                isotopicmaps  nowhere, really

   Nikita Ogievetsky XMLHack       tm?l-wg
   Jan Algermissen   isotopicmaps  sc34wg3
   Patrick Durusau   isotopicmaps  sc34wg3
   Derek Millar      isotopicmaps  sc34wg3
   Sean Johnson      isotopicmaps  tm?l-wg
   Robert Barta      XMLHack       tm?l-wg
   Michel Biezunski  isotopicmaps  sc34wg3
   Bernard Vatant    XMLHack       tm?l-wg
   Steve Pepper     isotopicmaps  orally

--
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >

Martin,

Your comments are very much appreciated.  They are on the mark
and I will change the draft accordingly.

Cheers,
Mary


>*Martin Bryan
>Thanks for circulating the first draft. Some comments for you to consider:
>
> >   c) The expression language used in TMCL shall be TMQL, or a suitable
> >      subset thereof.
>
>Firstly, DSDL will have a constraint language, probably based on Schematron.
>The requirements statement for TMCL should not rule out the use of this
>language for expressing topic map constraints. Secondly, your statement
>implies that TMQL will include means of expressing constraints, which is
>clearly not the case. TMQL will only be suitable for identifying the set of
>topic map components to which a constraint will apply. In other words it
>will provide the XPath equivalent for RDF's about statement. The above
>option should read:
>
>c) The expression language used in TMCL should re-use relevant parts of TMQL
>to identify which topic map components a set of constraints applies to.
>
>You then go on to say:
>
> > It may also  include but is not limited to the following.
> >
> > Definitions of Classes and relationships of Classes and Instances:
> > Explicily indicate topics as classes
> > Describe relationships as classes
>
>Both the above statements are ambiguous. What I think you mean are:
>
>Explicitly identify topics conforming to a specific constraint as belonging
>to a particular class of topics
>Explicitly identify assocaitions conforming to a specific constraint as
>belonging to a particular class of associations
>
>If I am right you should use these mroe explicit statements
>
>Martin Bryan
>IS-Thought: Thinkers for the Information Society
>29 Oldbury Orchard, Churchdown, Glos. GL3 2PU, UK
>Phone/Fax: 01452 714029 E-mail: martin@...
>
>Thought of the week:
>Is "being" necessary? Won't "known as" suffice?
>
>
>
>
>_______________________________________________
>sc34wg3 mailing list
>sc34wg3@...
>http://www.isotopicmaps.org/mailman/listinfo/sc34wg3

[Robert Barta]
>
> Here is one detail where I am not able to get my mind around:
>
> Whenever I do some constraining then some/most constraints will look
> like this:
>
>    "if this is a topic of a particular kind
>        then it must look like this and that"
>
>    or
>
>    "if this is a association of a particular kind
>        then it must look like this and that"
>
> As soon as I specify the situation "topic is of a kind" how strict can
> or should I actually do this or how strict should TMCL interpret this
> in the light that "is-instance-of" together with "subclasses"
> introduce implicitly transitivity?
>
> Example:
>
> We would like this constraint to hold for all developers:
>
>    forall [ $p (developer) ]              # if $p is an instance of a
developer
>      => exists [ (is-working-on-project)  # something holds, whatever...
>                  worker : $p ]
>
> Now we introduce a subclass
>
>    (is-subclass-of)
>    class    : developer
>    subclass : perl-hacker
>
> and now we expect that the constraint above also applies to the
> perl-hacker.
>
> Or do we?
>

Robert,

I would like to reformulate problem a little bit. I hope it will help
discussion.

If we have statement (constraint) like this:

forall [ $p (developer) ]  # if $p is an instance of a developer
=> exists [ (is-working-on-project) # something holds, whatever...
worker : $p ]

Or (in more neutral form :-)

forall $x (isa($x,developer) => exists $y (isa($y,is-working-onproject) &
playsRole($x,worker,$y))

****** Do we allow exceptions?! ******

Let's say that we don't. In this case if we know that

isa(john3000,developer)

We have to be compliant with constraint:

exists $y (
isa($y,is-working-onproject) &
playsRole(john3000,worker,$y)
)

It does not matter if later we add new fact: isa(john3000,perl-hacker).
Because we do not allow exceptions this new information cannot change what
we already know.

There are some "procedural" questions which we have to answer in this model.

Let's say that initially we only know that:  isa(john3000,perl-hacker).
How can we find that "john3000" has constraint declared for class
  "developer"? Also, how can we find all constraints if instance can belong
to multiple classes and we allow multiple inheritance for classes?

We can navigate up from instance to classes and super classes each time when
we need get list of constraints.

We also can propagate constraints from super class to subclass and by doing
that we can implement kind of constraints caching. So if we know that we
cache all constraints from super classes in specific class we do not need to
navigate to all super classes if we need to find constraints for specific
instance. We just can use cached constraints (propagated earlier). If we do
not modify classes often we can improve constraint engine performance.
Well.and we can package these constraints in class "template" or "schema" if
we want to.

But.as with any caching we have a problem of cache invalidation. If we
modify constraints in super class we have to propagate constraints down to
sub classes.

When we cache constraint from super class it makes sense to assign special
tag (constraint source) which should point out to original source of the
constraint. It helps to avoid applying cached constraints several times.

If we allow exceptions we play different game.In this case new information
can become inconsistent with what we have already. We should have mechanisms
to resolve conflicts, such as "In case of conflict, information from
subclass overwrites information from super class". Doable, but I think not
for "light" version.

That's what I have so far...

Dmitry

At 23:52 2003/02/09 +0100, Lars Marius Garshol wrote:

>* Mary Nishikawa
>|
>| I have compiled most if not all of the points discussed on and
>| agreed to on the TMCL-WG list so far and placed some additional
>| information into a Requirements Specification Template based on IEEE
>| Standard 830-1993.  Various ideas on specific functional requirments
>| had already been proposed, but they are not included here.
>
>Great work, Mary! This is an excellent beginning. Suddenly we are a
>lot closer to having a real requirements document.

Thanks for your prompt feedback!
I wanted to start with this preliminary framework and develop it from there.

>
>| What is the purpose of having a TMCL?
>
>Another purpose I believe TMCL should serve is to support optimization
>both of topic map storage and of TMQL queries, based on schema
>information. If you have a very strict schema you can use that to
>optimize certain things, and I think that's something that will become
>increasingly important with time.
>
>| The TMCL must define a standard way to explicitly indicate how
>| information item types and properties as defined in the Standard
>| Application Model for Topic Maps are to be constrained.
>
>I don't think TMCL users will think of their use of TMCL in these
>terms. They'll probably think more of constraining what topic
>characteristics topics may have and what structure associations may
>have. It's probably better to describe it this way.

Agreed.


>(BTW, I'd say "TMCL" and "TMQL" throughout, rather than "the TMCL" and
>"the TMQL".)

This is a stylistic matter and I was following the rules from my CBE days.
I need to hunt down  my copy of the IEEE Syle Guide.

>| WHAT IT MAY SPECIFY
>|
>| TMCL  may be  based on an XML syntax using XSDL/DTD/DSDL, or
>| in the very least one informative syntax would be provided.
>
>I think there are two separate aspects to this:
>
>  a) what syntax(es) TMCL should have, and
>
>  b) what the language model should be.
>
>For the first there are a number of possibilities:
>
>  1) Use an XML syntax, like OSL does,
>
>  2) Use a more human-friendly syntax, like AsTMa! does,
>
>  3) Not have any syntax at all, but use existing TM syntaxes and a set
>     of published subjects.
>
>For the second there are even more possibilities:
>
>  1) Consider the syntax a shorthand for alternative 3) above,
>
>  2) Have a declarative language arranged around topic and association
>     types (like OSL), or
>
>  3) Simply use collections of TMQL queries to formulate the schema.
>
>(There are more, but I can't formulate all of them now.)
>
>I think we should list all the possibilities and then carefully make a
>choice, either in the requirements document, or, if we feel that's too
>early, in each TMCL proposal.

This is good. Thanks.

>
>| It may also  include but is not limited to the following.
>|
>| Definitions of Classes and relationships of Classes and Instances:
>| Explicily indicate topics as classes
>| Describe relationships as classes
>| Describe kinds of classes
>| Represent regularities about class instances
>| Represent partially known information about instances
>
>Definition of the class hierarchy also belongs here, I think, which is
>sort of awkward, because that information will also be in the topic map.
>IMHO this is an argument for having a topic map representation of
>TMCL, independent of the syntax used.

I am not sure about this one and would like to hear from others.
Why would a syntax-independent description make a difference here.
Sorry, I don't follow your thinking here. It would seem the same to me
either way.

I am hoping everyone will continue to add to this list and then we can come
back and review them later.

>| Data Typing:
>| Provide data typing not currently defined in the SAM.
>
>This could perhaps be described as data typing of occurrence values.
>I think we should also state outright that we will reuse the data
>types in XML Schema: Part 2. OWL does this, and I think doing anything
>else would cause unnecessary incompatibilities with XML and RDF.

Agreed.

>
>| Validation and Exceptions:
>| Define which topic map information  item types and properties are allowed
>| (Validity constainst beyond what has already been defined by the SAM.)
>
>I'm not sure what you mean by this. Could you explain?

You are correct. This does not make sense.

What I meant to say was,

We need to look at the topic map information item type and properties (TM
constructs)  and define constraints that are not included in the TM model
now.

On the other had, we should not be including constraints that are already
included in the SAM.

The purpose of this was to state that there will be no redundancies between
the SAM and TMCL in terms of what is being defined.

It is just an general statement.

For example, you added "definition of Class Hierarchy" above, but wouldn't
this already be in the map and would not need to be defined by TMCL?



>| Issue: Seems to be a need to define a validating (strict) versus loose
>| validation or non validating.
>| We need to define these if we think that they are important.
>
>I would put in that it should be possible to control whether a schema
>is open or closed (or strict/loose). I think this will be necessary.
>For example, when publishing a TMCL schema for a set of published
>subjects the schema should be open, but particular applications will
>probably use closed schemas.
>
>(OSL has this at the topic map level as well as at the topic and
>association type level.)
>

This need more discussion, I think.

>| Some definitions from posts:
>|
>| Strict validating topic map application MUST ensure that only instances of
>| schema constructs exist in the map, ie only topics of types defined inthe
>| schema can exist and that all constraints defined arre conformed to in the
>| topic map.
>|
>| A validating topic map application MUST ensure that any structure tht can
>| be constrained conform to the constraints of the schema.
>|
>| ISSUE:  Why should we have two different conformance levels?
>
>See above. :)
>
>| If we had two levels of validation, what would they be?
>
>I think strict/loose (or open/closed) on the topic map level is
>enough. The language should be strong enough that you can express
>looseness on the topic/association type level directly.
>
>| Use of TMQL
>| The TMCL should make use of the TMQL. The TMCL may use the TMQL to
>| locate the information item or property to be constrained or the
>| TMQL may use the TMCL to identity particular situations and the task
>| of TMQL is only to generate output.
>
>I would remove the SAM-inspired language here and say "to locate the
>topic map constructs to be constrained". It's probably easier for
>people to understand that way.

I will use "TM constructs" instead of "information item or property"
throughout.

>
>| The TMCL may use schema information to create a UI or "template."
>
>You already have this above, don't you?

This may be redundant content. I may not have been sure where I wanted to
place this one. Thanks.

>
>| WHAT IT WILL NOT SPECIFY
>|
>| TMCL shall not be specified in terms of  any serialisation format for topic
>| maps.
>
>No? :)

OK, there seemed to be a general feeling on the list not to specify any
serialization format (have a TM representation independent of any syntax).

I was checking to see if anyone is really reading this :)

I guess this is not in the right place.

>
>| Any information item types or properties that are not defined as
>| part of the Standard Application Model will not be specified by the
>| Topic Map Constraint language.
>
>Actually, I'm not sure about that. It may be that data typing will be
>specified by adding new properties to the SAM, and we may find that we
>want to specify TMCL by extending the SAM in other ways.

Need some comments from others on this one, I think.
I am a little surprised by this and it would create more complexity.  If
this is what we plan to do we need to be really definite about it and
describe it clearly.

>
>| Definition:  Validity constraints defined by TMCL versus XTM.dtd
>
>The XTM DTD specifies the XTM syntax, but it doesn't actually specify
>any constraints at the topic map level. The DTD just follows the model
>itself, and doesn't go anywhere beyond that.

This is the kind of explanation I wanted in the requirements. Define the
difference between the meaning of validity constraint in XML versus TMCL.
Thanks.

>
>| Definitions of ontology and metamodel
>
>Do we need definitions of these terms at all? I'm not sure we need to
>use the terms in this document, so why define them?

I thought that we may need to have these in  tmcl goals.
Need some comments from others on this one.
If we are going to refer to OWL, we many need it to define it if we want to
describe the dependencies of TMCL with on other standards.

>
>| 3.3 Classes (object-oriented)
>| NOTE:These are here to illustrate the usage scenarios described in 3.2
>| Include syntax examples here too?
>
>If you want examples you can look at the OSL schemas that come with
>the Omnigator. There is one for the Italian Opera topic map, and also
>one for the Scripts and languages one.

I was going to create a few examples for functional requirements, and
needed examples for a usage scenario This would help. Thanks.

>
>| 3.7 Requirements for testing
>|
>| Need to be described in a canonical syntax?
>
>This should be 3.6, I think. Creating a formal test suite for TMCL is
>a good idea, I think, but probably better left for OASIS to do. I also
>think we don't need to do anything special to allow it. You can create
>a suite consisting of a set of topic maps and schemas, and a
>superstructure that tells you
>
>   a) which combinations of TMs and schemas should validate,
>
>   b) which ones should not,
>
>   c) which schemas contain syntax errors, and
>
>   d) which schemas contain semantic errors.

We can keep it here, or move it into the non requirements section, since
the we will not cover it.


>Issues that should be dealt with in this document that currently are
>not are:
>
>  - should there be a well-defined procedure for merging TMCL schemas?
>
>  - should TMCL schemas be able to affect merging?
>    <URL:
>
http://www.ontopia.net/omnigator/models/topic_complete.jsp?tm=tm-standards.xtm&i\
d=merge-use-of-schemas
>  >
>
>There's probably more, but I can't think of anything right now.

Thanks. I will add it. This was very, very useful.

Cheers,
Mary

* Lars Marius Garshol
|
| This should be 3.6, I think. Creating a formal test suite for TMCL is
| a good idea, I think, but probably better left for OASIS to do. I also
| think we don't need to do anything special to allow it. You can create
| a suite consisting of a set of topic maps and schemas, and a
| superstructure that tells you
|
|   a) which combinations of TMs and schemas should validate,
|
|   b) which ones should not,
|
|   c) which schemas contain syntax errors, and
|
|   d) which schemas contain semantic errors.

I forgot to say that our test suite for our OSL implementation is
structured this way, except that it does not distinguish between c)
and d).

--
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >

* Mary Nishikawa
|
| I have compiled most if not all of the points discussed on and
| agreed to on the TMCL-WG list so far and placed some additional
| information into a Requirements Specification Template based on IEEE
| Standard 830-1993.  Various ideas on specific functional requirments
| had already been proposed, but they are not included here.

Great work, Mary! This is an excellent beginning. Suddenly we are a
lot closer to having a real requirements document.

| What is the purpose of having a TMCL?

Another purpose I believe TMCL should serve is to support optimization
both of topic map storage and of TMQL queries, based on schema
information. If you have a very strict schema you can use that to
optimize certain things, and I think that's something that will become
increasingly important with time.

| The TMCL must define a standard way to explicitly indicate how
| information item types and properties as defined in the Standard
| Application Model for Topic Maps are to be constrained.

I don't think TMCL users will think of their use of TMCL in these
terms. They'll probably think more of constraining what topic
characteristics topics may have and what structure associations may
have. It's probably better to describe it this way.

(BTW, I'd say "TMCL" and "TMQL" throughout, rather than "the TMCL" and
"the TMQL".)

| WHAT IT MAY SPECIFY
|
| TMCL  may be  based on an XML syntax using XSDL/DTD/DSDL, or
| in the very least one informative syntax would be provided.

I think there are two separate aspects to this:

  a) what syntax(es) TMCL should have, and

  b) what the language model should be.

For the first there are a number of possibilities:

  1) Use an XML syntax, like OSL does,

  2) Use a more human-friendly syntax, like AsTMa! does,

  3) Not have any syntax at all, but use existing TM syntaxes and a set
     of published subjects.

For the second there are even more possibilities:

  1) Consider the syntax a shorthand for alternative 3) above,

  2) Have a declarative language arranged around topic and association
     types (like OSL), or

  3) Simply use collections of TMQL queries to formulate the schema.

(There are more, but I can't formulate all of them now.)

I think we should list all the possibilities and then carefully make a
choice, either in the requirements document, or, if we feel that's too
early, in each TMCL proposal.

| It may also  include but is not limited to the following.
|
| Definitions of Classes and relationships of Classes and Instances:
| Explicily indicate topics as classes
| Describe relationships as classes
| Describe kinds of classes
| Represent regularities about class instances
| Represent partially known information about instances

Definition of the class hierarchy also belongs here, I think, which is
sort of awkward, because that information will also be in the topic map.
IMHO this is an argument for having a topic map representation of
TMCL, independent of the syntax used.

| Data Typing:
| Provide data typing not currently defined in the SAM.

This could perhaps be described as data typing of occurrence values.
I think we should also state outright that we will reuse the data
types in XML Schema: Part 2. OWL does this, and I think doing anything
else would cause unnecessary incompatibilities with XML and RDF.

| Validation and Exceptions:
| Define which topic map information  item types and properties are allowed
| (Validity constainst beyond what has already been defined by the SAM.)

I'm not sure what you mean by this. Could you explain?

| Issue: Seems to be a need to define a validating (strict) versus loose
| validation or non validating.
| We need to define these if we think that they are important.

I would put in that it should be possible to control whether a schema
is open or closed (or strict/loose). I think this will be necessary.
For example, when publishing a TMCL schema for a set of published
subjects the schema should be open, but particular applications will
probably use closed schemas.

(OSL has this at the topic map level as well as at the topic and
association type level.)

| Some definitions from posts:
|
| Strict validating topic map application MUST ensure that only instances of
| schema constructs exist in the map, ie only topics of types defined inthe
| schema can exist and that all constraints defined arre conformed to in the
| topic map.
|
| A validating topic map application MUST ensure that any structure tht can
| be constrained conform to the constraints of the schema.
|
| ISSUE:  Why should we have two different conformance levels?

See above. :)

| If we had two levels of validation, what would they be?

I think strict/loose (or open/closed) on the topic map level is
enough. The language should be strong enough that you can express
looseness on the topic/association type level directly.

| Use of TMQL
| The TMCL should make use of the TMQL. The TMCL may use the TMQL to
| locate the information item or property to be constrained or the
| TMQL may use the TMCL to identity particular situations and the task
| of TMQL is only to generate output.

I would remove the SAM-inspired language here and say "to locate the
topic map constructs to be constrained". It's probably easier for
people to understand that way.

| The TMCL may use schema information to create a UI or "template."

You already have this above, don't you?

| WHAT IT WILL NOT SPECIFY
|
| TMCL shall not be specified in terms of  any serialisation format for topic
| maps.

No? :)

| Any information item types or properties that are not defined as
| part of the Standard Application Model will not be specified by the
| Topic Map Constraint language.

Actually, I'm not sure about that. It may be that data typing will be
specified by adding new properties to the SAM, and we may find that we
want to specify TMCL by extending the SAM in other ways.

| Definition:  Validity constraints defined by TMCL versus XTM.dtd

The XTM DTD specifies the XTM syntax, but it doesn't actually specify
any constraints at the topic map level. The DTD just follows the model
itself, and doesn't go anywhere beyond that.

| Definitions of ontology and metamodel

Do we need definitions of these terms at all? I'm not sure we need to
use the terms in this document, so why define them?

| 3.3 Classes (object-oriented)
| NOTE:These are here to illustrate the usage scenarios described in 3.2
| Include syntax examples here too?

If you want examples you can look at the OSL schemas that come with
the Omnigator. There is one for the Italian Opera topic map, and also
one for the Scripts and languages one.

| 3.7 Requirements for testing
|
| Need to be described in a canonical syntax?

This should be 3.6, I think. Creating a formal test suite for TMCL is
a good idea, I think, but probably better left for OASIS to do. I also
think we don't need to do anything special to allow it. You can create
a suite consisting of a set of topic maps and schemas, and a
superstructure that tells you

   a) which combinations of TMs and schemas should validate,

   b) which ones should not,

   c) which schemas contain syntax errors, and

   d) which schemas contain semantic errors.


Issues that should be dealt with in this document that currently are
not are:

  - should there be a well-defined procedure for merging TMCL schemas?

  - should TMCL schemas be able to affect merging?
    <URL:
http://www.ontopia.net/omnigator/models/topic_complete.jsp?tm=tm-standards.xtm&i\
d=merge-use-of-schemas >

There's probably more, but I can't think of anything right now.

--
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >

Hi,

Here is one detail where I am not able to get my mind around:

Whenever I do some constraining then some/most constraints will look
like this:

    "if this is a topic of a particular kind
        then it must look like this and that"

    or

    "if this is a association of a particular kind
        then it must look like this and that"

As soon as I specify the situation "topic is of a kind" how strict can
or should I actually do this or how strict should TMCL interpret this
in the light that "is-instance-of" together with "subclasses"
introduce implicitly transitivity?

Example:

We would like this constraint to hold for all developers:

    forall [ $p (developer) ]              # if $p is an instance of a developer
      => exists [ (is-working-on-project)  # something holds, whatever...
                  worker : $p ]

Now we introduce a subclass

    (is-subclass-of)
    class    : developer
    subclass : perl-hacker

and now we expect that the constraint above also applies to the
perl-hacker.

Or do we?

My point is: If the ontology engineer specifies

    "topic is-a something"

should automatically kick in subclass transitivity and should this
be interpreted as

    "topic is-a something (or any subclass thereof)"

On the plus-side we can say that rules like this are much more
robust. On the other side, should it be possible for someone to say:

    "topic is-a something AND NO subclass of it"

or should the language forbid this totally?

\rho

Hi,

Thank you very much in providing initial feedback on the TMCL. I am very
encouraged to work with such an enthusiastic and knowledgeable group of
people.  If I missed your comments, or misrepressented anything please
forgive me and correct it immediately!

I have compiled most if not all of the points discussed on and agreed to on
the TMCL-WG list so far and placed some additional information into a
Requirements Specification Template based on IEEE Standard 830-1993.
Various ideas on specific functional requirments had already been proposed,
but they are not included here.

What is also not included here are various TMCL ideas and discussions that
have taken place on the SC34WG3 or topicmapmail lists.

If you want to contribute to TMCL, please do so through the TMCL-WG list.
Thanks.

I will send out a separate request for functional requirements and how to
submit these.

This is in a pre draft state. After receiving your contributions of
functional requirements, and other necessary additions this will become a
working draft. Please comment and suggest content for missing parts or
categories that are not needed. Thank you.

Cheers,
Mary

---------------------------------
Requirements for a
Topic Map Constraint Language (TMCL)

Source: TMCL-WG
Rrequirement Editors: Graham Moore, Mary Nishikawa
Project Editor: Steve Pepper

1. Introduction

1.1 Purpose of the document

What is the goal of the project?
What is the purpose of having a TMCL?
Who Should read this document?


The Topic Map Constraint Language (TMCL) will  provide a means of
validation over and above the constraints currently defined by the Standard
Application Model. It's goal will be to ensure consistency within a topic
map or within a class of topic maps.

It may provide more intuitive user interfaces for creating and maintaining
topic maps.


1.2 Scope of the Language

Exactly what are you specifying?
What will not be specified?
Are there any limitations?

WHAT IT MUST SPECIFY

The TMCL must define a standard way to explicitly indicate how information
item types and properties as defined in the Standard Application Model for
Topic Maps are to be constrained.

TMCL shall be specified in terms of the SAM.  This will automatically allow
it to support both XTM & HyTM s well as LTM and AsTMa=, since these all
have mappings to the SAM.

WHAT IT MAY SPECIFY

TMCL  may be  based on an XML syntax using XSDL/DTD/DSDL, or
in the very least one informative syntax would be provided.

This may include

    - a fully-fledged expression language
   a) TMCL shall support detailed constraints through the use of an
      expression language.

    - a more down-to-earth 'lite' version for those who live more on the
      template level
   b) TMCL shall support simple declarative constraints that do not
      require the use of an expression language.

   c) The expression language used in TMCL shall be TMQL, or a suitable
      subset thereof.

It may also  include but is not limited to the following.

Definitions of Classes and relationships of Classes and Instances:
Explicily indicate topics as classes
Describe relationships as classes
Describe kinds of classes
Represent regularities about class instances
Represent partially known information about instances

Cardinality:
Cardinality of infomation item types and properties

Data Typing:
Provide data typing not currently defined in the SAM.

Validation and Exceptions:
Define which topic map information  item types and properties are allowed
(Validity constainst beyond what has already been defined by the SAM.)
Allow any topic map instance element to be constrained, ie, not just topics
and associations, but names resource references, variants, etc.

1. Must define set of validation exceptions and should be unambiguous as to
what validation exceptions are possible
2. Define the operational semantics of validation and set of validation
exceptions.

Application of the constraint language without a validation requirement
The schema may imply templating  or prototyping but does not necessarily
require validation.

Application of the constraint language with validation.

(May or may not be a validation requirement?)

Issue: Seems to be a need to define a validating (strict) versus loose
validation or non validating.
We need to define these if we think that they are important.

Some definitions from posts:

Strict validating topic map application MUST ensure that only instances of
schema constructs exist in the map, ie only topics of types defined inthe
schema can exist and that all constraints defined arre conformed to in the
topic map.

A validating topic map application MUST ensure that any structure tht can
be constrained conform to the constraints of the schema.

ISSUE:  Why should we have two different conformance levels?

If we had two levels of validation, what would they be?


Use of TMQL
The TMCL should make use of the TMQL. The TMCL may use the TMQL to locate
the information item or property to be constrained or the TMQL may use the
TMCL to identity particular situations and the task of TMQL is only to
generate output.

The TMCL may use schema information to create a UI or "template."

Use of Topic Map Published Subjects indicators


WHAT IT WILL NOT SPECIFY

TMCL shall not be specified in terms of  any serialisation format for topic
maps.

It will not state when these constraints are applied.

It will not define domain or vertical market ontologies however these may
be used for illustrative purposes in usage scenarios.

Any information item types or properties that are not defined as part of
the Standard Application Model will not be specified by the Topic Map
Constraint language.


1.3 Definitions, Acronyms and Abbreviations

The keywords "MUST,"  "MUST NOT,"  "REQUIRED,"  "SHALL,"  "SHALL NOT,"
"SHOULD,"  "SHOULD NOT,"  "RECOMMEND," "MAY," and "OPTIONAL will be used in
this document as defined in [RFC 2119].

Definition:  Validity constraints defined by TMCL versus XTM.dtd

Definitions of ontology and metamodel

From: Pidcock, Woody
Sent: 13 January 2003 22:42
Subject: DRAFT Ontology FAQ

An ontology is a controlled vocabulary and a grammar for using that
vocabulary to express something meaningful within a specified domain of
interest.  The grammar contains formal constraints (e.g., specifies what it
means to be a well-formed statement, assertion, query, etc.) on how terms in
the ontology's controlled vocabulary can be used together. People make
commitments to use a specific ontology for a specific domain of interest.
Enforcement of an ontology's grammar may be rigorous or lax.  Frequently,
the grammar for an ontology is not completely specified, i.e., it has
implicit rules that are not explicitly documented.

A meta-model is an explicit model of the constructs and rules needed to
build specific models within a domain of interest.  A valid meta-model is an
ontology, but not all ontologies are modeled explicitly as meta-models.  A
meta-model can be viewed from three different perspectives:
(1) as a set of building blocks and rules used to build models
(2) as a model of a domain of interest, and
(3) as an instance of another model.


Editor note: need to collect definitions as required.

1.4 References

Editor note: need to collect references as required.


2. Overview of the TMCL Requirements

2.1 TMCL Perspective

Describe the relation to other Topic map standards, the XML infoset and any
other standards or recommendations.

   Pre-existing specifications and established best practice for knowledge
representation and data modeling will contribute to the function requirements.
These include OWL, DAML/OIL, KIF, OKBC,OCL, PAL (Protege Axiom Language),
and XML Schema. Some aspects of TMCL my depend heavily on one or more of these.


2.2 TMCL Functions

Describe the Main functions that the TMCL must perform

2.3 User Characteristics

Who will use the language?  ---
Implementers writing interfaces (expression language) data modelers,
designers of system ontologies

2.4 General Constraints

Describe limitations and Constraints

2.5 Assumptions and Dependencies

List factors that can  affect the requirements. What if changed, will
change the requirements.

3. Specific Requirements

3.1 Business Requirements (there was a reques to separate out business
requirements from Functional requirements -- I don't have any business
requirements now- unless I missed them.)

Business Requirement #1


3.2 Functional Requirements (These should be very specific and relate to
the information items in the SAM.)

Functional Requirement #1
Source: Name person submitting the requirement.
Criticality: "MUST,"  "MUST NOT,"  "REQUIRED,"  "SHALL,"  "SHALL NOT,"
"SHOULD,"  "SHOULD NOT,"  "RECOMMEND," "MAY," and "OPTIONAL
Definition:
Information flow (how is the information flowing between parts?)
Process description (usage scenario)
Define Data constructs if any (data types, arrays, class fields, etc.)
data dictionary (A list of all data items in the function. Should at least
have name and data type -- short explanation, life span acuracy, which
functions or processes the data is used in.)

Functional Requirement #2
Source: Name person submitting the requirement.
Criticality: "MUST,"  "MUST NOT,"  "REQUIRED,"  "SHALL,"  "SHALL NOT,"
"SHOULD,"  "SHOULD NOT,"  "RECOMMEND," "MAY," and "OPTIONAL
Definition:
Information flow (how is the information flowing between parts?)
Process description (usage scenario)
Define Data constructs if any (data types, arrays, class fields, etc.)
data dictionary (A list of all data items in the function. Should at least
have name and data type -- short explanation, life span acuracy, which
functions or processes the data is used in.)


3.3 Classes (object-oriented)
NOTE:These are here to illustrate the usage scenarios described in 3.2
Include syntax examples here too?

Can use some class examples that would refer to functional requirements
described above.
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.

Source (Dymtry)
1. I see here something like that:
isa(instance:server,class:metaClass)

2. superclass-subclass is just basic relationship here. There are some
others:
isDefinedByInstances(
      class:Continent,
      instance:Eurasia,
      instance: Africa,
      instance:North_America,
      instance:South_America,
      instance:Australia,
      instance: Antarctica),
for example.

3. Personally, I see value in separating classes as basic, abstract  and
specializations. So I see here something like that:
isa(instance:server,class:metaClass),
isa(instance:server,class:basicClass),
subclass(subclass:basicClass,superclass:metaClass),
isa(instance:sqlServer,class:spesializationClass),
subclass(subclass:sqlServer,superclass:server)

4. Something like that:
eachHasToHaveResourceOccurrence(
      subjectClass:server,
      resourceClass:serverDescription),

eachHasToHaveDataOccurrence(
      subjectClass:server,
      resourceClass:installationDate,
      resourceDataClass:date),

eachDefinesClassRestrictionOnInstancePlayingRole(
      objectClass:server,
      objectAssociationRole: objectOfOwnership,
      associationClass:ownership,
      otherObjectAssociationRole:owner,
      otherObjectClassRestriction:itSpecialist)

5. Something like that:

hasCardinalityRestrictionOnNumberOfInstancesPlayingRole (
      instance:john3000,
      instanceRole:who,
      associationClass:hasSisters,
      restrictedRole:sisters,
      cardinalityRestriction:2)


3.4 Design Constraints
standards compliance,  limitations

3.5 Quality Attributes or Non Functional attributes

reliability
availability
security
maintability
portability
binary compatibility
usability
versioning
data updating
Resource utilization
serviceability
internationalization

3.7 Requirements for testing

Need to be described in a canonical syntax?

3.7 Non Requirements

Describe in detail what will not be addressed.

3.8 Risks

On Fri, Feb 07, 2003 at 05:14:42PM +0000, Anthony B. Coates wrote:
> ** Reply to message from Robert Barta <rho@...> on Fri, 7 Feb 2003
> 06:57:15 +1000
>
> > I do not see it too difficult to define a sublanguage (TMCL-lite? :-)
> > which is more along the template-only approach and which can be
> > represented in a map and serialized into XTM in a straightforward way.
>
> [ ... snip ... ]
>
> > This can be translated automatically into TMCL-professional
>
> Actually, I would advise against one-way conversion of a TMCL-lite to
TMCL-pro.
> I have had too many bad experiences with one-way code "wizards".  Just because
> someone wants to use one "pro" feature, they shouldn't find that their whole
> TMCL document has suddenly changed completely.

No, that would not be good. The translation should happen behind the
scenes as long as possible:

-------------------------------------------------
# here I am in a file with complex and simpler constraints

# complex constraint 1: all politicians are crooks
forall $p [ * (politician) ]
   => exists $p [ * (crook) ]

# constraint 2 can be done as template

%xtm:on # switches from AsTMa! to XTM mode
<topic id=.....
    .....template stuff here
</topic>
%xtm:off #AsTMa! mode again

# constraint 3
....

-------------------------------------------------

So it could be even mixed within one document without the user being
fully aware of the translation.

> What I meant is that it should be possible to just add TMQL
> constraints to a TM "prototype" to achieve the full set of desired
> constraints.  I don't see why the prototypical constraints need be
> changed to TMQL constraints.  I mean, if somebody *wants* to do such
> a conversion, I won't stop them, but I think users would benefit
> most from an integrated approach which allows both paradigms to work
> together.

Yes, this should be exactly the way as above.

\rho

** Reply to message from Robert Barta <rho@...> on Fri, 7 Feb 2003
06:57:15 +1000

> I do not see it too difficult to define a sublanguage (TMCL-lite? :-)
> which is more along the template-only approach and which can be
> represented in a map and serialized into XTM in a straightforward way.

[ ... snip ... ]

> This can be translated automatically into TMCL-professional

Actually, I would advise against one-way conversion of a TMCL-lite to TMCL-pro.
I have had too many bad experiences with one-way code "wizards".  Just because
someone wants to use one "pro" feature, they shouldn't find that their whole
TMCL document has suddenly changed completely.  What I meant is that it should
be possible to just add TMQL constraints to a TM "prototype" to achieve the
full set of desired constraints.  I don't see why the prototypical constraints
need be changed to TMQL constraints.  I mean, if somebody *wants* to do such a
conversion, I won't stop them, but I think users would benefit most from an
integrated approach which allows both paradigms to work together.

	 Cheers,
		 Tony.
====
Anthony B. Coates, Information & Software Architect
mailto:abcoates@...
Reuters Messaging: abcoates.londonmarketsystems.com@...
====
MDDL Editor (Market Data Definition Language), http://www.mddl.org/
FpML AWG Member (Financial Products Markup Language), http://www.fpml.org/

Thomas,

But this is true for RDF as well (RDF is a concept and
XML is only *one* possibel interchange syntax) and RDF
is listed at XMLhack.

--Holger

--
Dr. H. Holger Rath
- Head of Consulting -

empolis * GmbH
arvato knowledge management
part of arvato: a Bertelsmann company
Europaallee 10
67657 Kaiserslautern, Germany

phone :  +49-172-66-90-427
fax   :  +49-631-303-5507

<mailto:holger.rath@...>
http://www.empolis.com


-----Original Message-----
From: Bandholtz, Thomas [mailto:TBandholtz@...]
Sent: Friday, February 07, 2003 10:32 AM
To: 'tmcl-wg@yahoogroups.com'; tmql-wg@yahoogroups.com
Cc: sc34wg3@...
Subject: RE: [tmcl-wg] TM?L mail lists move




> Why don't we have the lists on isotopicmaps.org,
This might be the "natural" home.
> and ask Ed
> to post the
> link to our mail group on the xml Hack home page under Key
> XML Resources.
> This seems to be the best solution.
Is isotopicmaps.org really a Key *XML* Resource? I don't doubt the "Key
Resource", but XML is only the language of one of it's interchange formats.
The core standard is a concept, not about XML.
Thomas

To unsubscribe from this group, send an email to:
tmcl-wg-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Sorry for late answer.

Following recent arguments, I agree we're better on isotopicmaps.org
Mary's proosal of having a link from XML Hack is good of course.

Bernard

_____________________________________

Bernard Vatant
Senior Consultant - Knowledge Engineering
www.mondeca.com
_____________________________________

| -----Original Message-----
| From: Mary Nishikawa [mailto:nisikawa@...]
| Sent: vendredi 7 février 2003 01:58
| To: tmcl-wg@yahoogroups.com
| Cc: tmcl-wg@yahoogroups.com
|
| Lars Marius,
|
| I have these + votes for XML Hack posted on tmcl-wg list;
|
| Thomas Bandholtz, Graham Moore,  (before choice)
| Marc De Graaw,  not definite
|
| Nikita Ogievetsky, and Bernard Vatant and Steve Pepper (+ vote for XML
| Hack
| after choice between two)
|
| These need to be added to the + xml Hack vote, unless they have
changed
| their minds. Please speak up. :)
|
| Let's get confirmation from  Thomas, Graham, and Marc before this vote
is
| closed. Thank you.
|
| Cheers,
| Mary
|
|
| > >
| > >   Who               What          Where
| > >   ----------------- ----------------------------
| > >   Kal Ahmed         XMLhack       tm?l-wg
| > >   Holger Rath       XMLhack       tm?l-wg
| > >   Mary Nishikawa    XMLhack       tm?l-wg
| > >   Tony Coates       XMLhack       tm?l-wg
| > >   Sam Hunting       isotopicmaps  sc34wg3
| > >   Jim Mason         isotopicmaps  sc34wg3
| > >   me                isotopicmaps  nowhere, really
| > >
| > > I'm setting 2003-02-07 2400 UTC as the deadline for this vote. I
| > > suggest that whichever alternative has the most votes by then is
what
| > > we'll go for.
| > >
| > > (Oh, and do let me know if I've left someone out.)
| > >
| > > --
| > > Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net
>
| > > GSM: +47 98 21 55 50                  <URL:
http://www.garshol.priv.no
| >
| > >
| > > _______________________________________________
| > > sc34wg3 mailing list
| > > sc34wg3@...
| > > http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
| >
| >--
| >Jan Algermissen                           http://www.topicmapping.com
| >Consultant & Programmer                   http://www.gooseworks.org
| >
| >To unsubscribe from this group, send an email to:
| >tmql-wg-unsubscribe@egroups.com
| >
| >
| >
| >Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
|
|
| ------------------------ Yahoo! Groups Sponsor
|
| To unsubscribe from this group, send an email to:
| tmcl-wg-unsubscribe@yahoogroups.com
|
|
|
| Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
|

> Why don't we have the lists on isotopicmaps.org,

This might be the "natural" home.

> and ask Ed
> to post the
> link to our mail group on the xml Hack home page under Key
> XML Resources.
> This seems to be the best solution.

Is isotopicmaps.org really a Key *XML* Resource? I don't doubt the "Key Resource", but XML is only the language of one of it's interchange formats. The core standard is a concept, not about XML.

Thomas

Hi,

This is a very good idea, Mary!

So I change my vote to: iff new mailing lists get listed at XMLhack
I vote for having them at isotopicmaps.org. If not I still vote for
XMLhack as a host.

Regards,
--Holger


> -----Original Message-----
> From: Mary Nishikawa [mailto:nisikawa@...]
> Sent: Friday, February 07, 2003 7:33 AM
> To: tmcl-wg@yahoogroups.com; tmql-wg@yahoogroups.com
> Cc: sc34wg3@...
> Subject: [tmcl-wg] TM?L mail lists move
>
>
>
> >*LMG
> >So far we have the following votes on the XMLhack.com vs
> >isotopicmaps.org issue, which means that it's quite evenly balanced.
>
> I have another idea after looking at the XML Hack site.
>
> Why don't we have the lists on isotopicmaps.org, and ask Ed
> to post the
> link to our mail group on the xml Hack home page under Key
> XML Resources.
> This seems to be the best solution.
>
> The mail lists posted here are not hosted by xml-hack.
> Our Web site: isotopicmaps.org should also be listed, as well as our
> Specifications and Organization.
>
> See below.
>
> Cheers,
> Mary
> ---------------------------
> Key XML resources
> Mailing lists
> xml-dev
> xml-l
> xsl-list
> www-rdf-interest
> xhtml-l
>  > more lists...
>
> Web sites
> XML.com
> Robin Cover's SGML/XML page
> XML FAQ
> Eclectic (xml-dev)
> Cafe con Leche
> WDVL XML
> XSLT.com
> XMLfr
> RDF @ W3C
> SOAP WRC
> XML-RPC.com
>
>   Specifications
> XML 1.0
> XSLT
> RDF
> XPath
> XPointer
> XLink
> Namespaces
> XHTML
> RELAX NG
> XML Schema: 1 2
> DOM Level: 1 2
> CSS Level: 1 2 3
>
> Organizations
> W3C
> OASIS
> IETF
> Dublin Core MI
>
> Repositories
> XML.org
> biztalk.org
> schema.net
>
>
>
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Get 128 Bit SSL Encryption!
> http://us.click.yahoo.com/LIgTpC/vN2EAA/xGHJAA/2U_rlB/TM
> --------------------------------------------------------------
> -------~->
>
> To unsubscribe from this group, send an email to:
> tmcl-wg-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

>*LMG
>So far we have the following votes on the XMLhack.com vs
>isotopicmaps.org issue, which means that it's quite evenly balanced.

I have another idea after looking at the XML Hack site.

Why don't we have the lists on isotopicmaps.org, and ask Ed to post the
link to our mail group on the xml Hack home page under Key XML Resources.
This seems to be the best solution.

The mail lists posted here are not hosted by xml-hack.
Our Web site: isotopicmaps.org should also be listed, as well as our
Specifications and Organization.

See below.

Cheers,
Mary
---------------------------
Key XML resources
Mailing lists
xml-dev
xml-l
xsl-list
www-rdf-interest
xhtml-l
  > more lists...

Web sites
XML.com
Robin Cover's SGML/XML page
XML FAQ
Eclectic (xml-dev)
Cafe con Leche
WDVL XML
XSLT.com
XMLfr
RDF @ W3C
SOAP WRC
XML-RPC.com

   Specifications
XML 1.0
XSLT
RDF
XPath
XPointer
XLink
Namespaces
XHTML
RELAX NG
XML Schema: 1 2
DOM Level: 1 2
CSS Level: 1 2 3

Organizations
W3C
OASIS
IETF
Dublin Core MI

Repositories
XML.org
biztalk.org
schema.net

Lars Marius,

I have these + votes for XML Hack posted on tmcl-wg list;

Thomas Bandholtz, Graham Moore,  (before choice)
Marc De Graaw,  not definite

Nikita Ogievetsky, and Bernard Vatant and Steve Pepper (+ vote for XML Hack
after choice between two)

These need to be added to the + xml Hack vote, unless they have changed
their minds. Please speak up. :)

Let's get confirmation from  Thomas, Graham, and Marc before this vote is
closed. Thank you.

Cheers,
Mary


> >
> >   Who               What          Where
> >   ----------------- ----------------------------
> >   Kal Ahmed         XMLhack       tm?l-wg
> >   Holger Rath       XMLhack       tm?l-wg
> >   Mary Nishikawa    XMLhack       tm?l-wg
> >   Tony Coates       XMLhack       tm?l-wg
> >   Sam Hunting       isotopicmaps  sc34wg3
> >   Jim Mason         isotopicmaps  sc34wg3
> >   me                isotopicmaps  nowhere, really
> >
> > I'm setting 2003-02-07 2400 UTC as the deadline for this vote. I
> > suggest that whichever alternative has the most votes by then is what
> > we'll go for.
> >
> > (Oh, and do let me know if I've left someone out.)
> >
> > --
> > Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
> > GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >
> >
> > _______________________________________________
> > sc34wg3 mailing list
> > sc34wg3@...
> > http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
>
>--
>Jan Algermissen                           http://www.topicmapping.com
>Consultant & Programmer                   http://www.gooseworks.org
>
>To unsubscribe from this group, send an email to:
>tmql-wg-unsubscribe@egroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

On Thu, Feb 06, 2003 at 11:54:48AM +0000, Anthony B. Coates wrote:
> Some of the early discussion of how TMCL might be implemented revolved around
> having some kind of prototypical Topic Map which was understood to define (a)
> the allowed topic types, (b) the allowed association types, (c) the allowed
> member types for each association type, and (d) the allowed occurrence types
> for each topic type.  Now, (a) to (d) certainly don't give you everything you
> might want in a TMCL, but I would argue that from an 80/20 perspective, they
> cover the most common requirements.
>
> Given that there are already people asking whether TMCL instances will
> themselves be Topic Maps, I wonder whether it would be worth considering if
the
> combination of a prototypical Topic Map + auxiliary TMQL expressions could
> provide a TMCL solution that is easy to get started with (using prototype
Topic
> Maps), but has the extra power there when you need it, just as Schematron adds
> to other XML schema languages.

Antony,

I think this is a good idea and I think it was also shortly discussed
before (IRC?).

I do not see it too difficult to define a sublanguage (TMCL-lite? :-)
which is more along the template-only approach and which can be
represented in a map and serialized into XTM in a straightforward way.

So, for example, similar to the original Pepper proposal, completely ad-hoc:

    <topic id="person-template">
       <instanceOf><topicRef xlink:href="#person"/></instanceOf>
       <baseName tmcl:minimal="1">
          <baseNameString>xxxxx</baseNameString>
       </baseName>
       <occurrence tmcl:matchregex="^http://">
         <resourceRef xlink:href="http://something....."/>
       </occurrence>
    </topic>

[ I freely add other namespaces to XTM here ].

This can be translated automatically into TMCL-professional (bloody
marketing ;-)) as

  "whenever a topic is of class person

      => the topic must be of this form:

                has at least one basename
                link must match http://

  "

This provides also a good migration path as user can use both and
switch to the full language (uhm, TMCL professional) at any time.

And for people _only_ interesting in generating forms from this even
an XSLT could do.

\rho

On Thu, Feb 06, 2003 at 08:16:00PM +0100, Lars Marius Garshol wrote:
> So far we have the following votes on the XMLhack.com vs
> isotopicmaps.org issue, which means that it's quite evenly balanced.
> If you have an opinion on this, please express it *now*.
>
>   Who               What          Where
>   ----------------- ----------------------------

     Robert Barta      tm?l-wg       XMLHack

\rho

>   Kal Ahmed         XMLhack       tm?l-wg
>   Holger Rath       XMLhack       tm?l-wg
>   Mary Nishikawa    XMLhack       tm?l-wg
>   Tony Coates       XMLhack       tm?l-wg
>   Sam Hunting       isotopicmaps  sc34wg3
>   Jim Mason         isotopicmaps  sc34wg3
>   me                isotopicmaps  nowhere, really

-----Original Message-----
From: Lars Marius Garshol [mailto:larsga@...]
Sent: Thursday, February 06, 2003 2:44 PM
To: tmql-wg@yahoogroups.com
Cc: sc34wg3@...; tmcl-wg@yahoogroups.com
Subject: Re: [tmcl-wg] Where to, tm?l-wg?

* Jan Algermissen
|
| Well, I have no official vote (in case that is needed here) but I
| follow Sam's argument that moving the lists to isotopicmaps
| supports marketing the 'brand' (iso-) topic maps.

Counts as a vote for me. These lists are used by individuals, and so I
think we should count votes that way, too.

--
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >


To unsubscribe from this group, send an email to:
tmcl-wg-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

* Jan Algermissen
|
| Well, I have no official vote (in case that is needed here) but I
| follow Sam's argument that moving the lists to isotopicmaps
| supports marketing the 'brand' (iso-) topic maps.

Counts as a vote for me. These lists are used by individuals, and so I
think we should count votes that way, too.

--
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >

(Apologies for the blatant cross-posting.)

So far we have the following votes on the XMLhack.com vs
isotopicmaps.org issue, which means that it's quite evenly balanced.
If you have an opinion on this, please express it *now*.

   Who               What          Where
   ----------------- ----------------------------
   Kal Ahmed         XMLhack       tm?l-wg
   Holger Rath       XMLhack       tm?l-wg
   Mary Nishikawa    XMLhack       tm?l-wg
   Tony Coates       XMLhack       tm?l-wg
   Sam Hunting       isotopicmaps  sc34wg3
   Jim Mason         isotopicmaps  sc34wg3
   me                isotopicmaps  nowhere, really

I'm setting 2003-02-07 2400 UTC as the deadline for this vote. I
suggest that whichever alternative has the most votes by then is what
we'll go for.

(Oh, and do let me know if I've left someone out.)

--
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >

> At the moment I dont see TMCL in an XPath like fashion, I see TMQL
> more in that light. I see TMCL as a binding of TMQL expressions into
> what can be called a constrint. something like :
>
> tmcl expression : Given the thing at [tmql expression] the thing [tmql
expression] must be > 1.

Formally, you could construct TMCL out of TMQL expressions that have boolean
results which must evaluate to 'true' (assuming TMQL does that kind of thing).
However, this would make it very much like Schematron.  Currently, Schematron
is rarely used to create full Schemas, because it is more verbose then even W3C
XML Schema in expressing "this element contains these other elements" and
standard constructs like that.  Instead, Schematron seems to more often be
filling a role of a secondary Schema.  After you have used your main schema
(DTD, W3C XML Schema, RELAX NG), you can then use Schematron to add rules that
couldn't be expressed in your schema language (although note that Schematron
can't express all of the rules you could want).

Some of the early discussion of how TMCL might be implemented revolved around
having some kind of prototypical Topic Map which was understood to define (a)
the allowed topic types, (b) the allowed association types, (c) the allowed
member types for each association type, and (d) the allowed occurrence types
for each topic type.  Now, (a) to (d) certainly don't give you everything you
might want in a TMCL, but I would argue that from an 80/20 perspective, they
cover the most common requirements.

Given that there are already people asking whether TMCL instances will
themselves be Topic Maps, I wonder whether it would be worth considering if the
combination of a prototypical Topic Map + auxiliary TMQL expressions could
provide a TMCL solution that is easy to get started with (using prototype Topic
Maps), but has the extra power there when you need it, just as Schematron adds
to other XML schema languages.

At the very least, before going with any particular paradigm for TMCL, we
should ask the question "does it make it simple to define simple sets of
constraints".

	 Cheers,
		 Tony.
====
Anthony B. Coates, Information & Software Architect
mailto:abcoates@...
Reuters Messaging: abcoates.londonmarketsystems.com@...
====
MDDL Editor (Market Data Definition Language), http://www.mddl.org/
FpML AWG Member (Financial Products Markup Language), http://www.fpml.org/

Dmitry,

I did not see a response to this yet.

On Mon, Jan 27, 2003 at 09:32:23PM -0500, Dmitry wrote:
> What I think we need:
>
> TMCL should define standard way to:
> 1. explicitly indicate some topics as classes

> 1. I see here something like that:
> isa(instance:server,class:metaClass)

Yes, this is one use case:

   
http://topicmaps.bond.edu.au/mda/rho/tmcl-constraints/topic-only-for-topic-typin\
g

> 2. describe relationships between classes (and instances when class is
> described by instances)

> 2. superclass-subclass is just basic relationship here. There are some
> others:
> isDefinedByInstances(
>     class:Continent,
>     instance:Eurasia,
>     instance: Africa,
>     instance:North_America,
>     instance:South_America,
>     instance:Australia,
>     instance: Antarctica),
> for example.

Can this be equivalently translated into

   "If I find a topic of class 'Continent' then it must be either
    Eurasia, ..... and NOTHING else"?

What other generic relationships between classes are you thinking
about?

> 3. describe different kinds of classes

> 3. Personally, I see value in separating classes as basic, abstract  and
> specializations. So I see here something like that:
> isa(instance:server,class:metaClass),
> isa(instance:server,class:basicClass),
> subclass(subclass:basicClass,superclass:metaClass),
> isa(instance:sqlServer,class:spesializationClass),
> subclass(subclass:sqlServer,superclass:server)

What is there exactly which cannot be expressed with (X)TM?

> 4. represent regularities about class instances
> 4. Something like that:
> eachHasToHaveResourceOccurrence(
>     subjectClass:server,
>     resourceClass:serverDescription),
>
> eachHasToHaveDataOccurrence(
>     subjectClass:server,
>     resourceClass:installationDate,
>     resourceDataClass:date),

Yes, we need a way to define

  (a) that topic of a particular nature must have particular
      characteristics (name, link occurrence, resourceData, ....)

  (b) associations of a particular nature must have a specified form

> eachDefinesClassRestrictionOnInstancePlayingRole(
>     objectClass:server,
>     objectAssociationRole: objectOfOwnership,
>     associationClass:ownership,
>     otherObjectAssociationRole:owner,
>     otherObjectClassRestriction:itSpecialist)

What is the semantics of this?

> 5. represent partially known  information about instances
> 5. Something like that:
>
> hasCardinalityRestrictionOnNumberOfInstancesPlayingRole (
>     instance:john3000,
>     instanceRole:who,
>     associationClass:hasSisters,
>     restrictedRole:sisters,
>     cardinalityRestriction:2)

Is this "for every association 'hasSister' where john3000 plays the who
we need that this association contains exactly two topics playing sister?

foreach $a [ (hasSisters)
              who : john3000 ]
   => exists $s [ (hasSisters)
                  sister{2} : * ]


\rho

On Thu, Jan 30, 2003 at 08:12:15AM -0000, Graham Moore wrote:
> The 'want?' you refer to, was meant simply to say that even though
> the schema/constraints say that a particular role player should be
> of type 'Person' and that the gui initially provides a list of all
> 'Person' topics, that the user can still be free, if she so chooses,
> to select any kind of topic to play that role. In different levels
> of conforming application this would have different effects.

Right, but this is outside the scope of TMCL.

> At the moment I dont see TMCL in an XPath like fashion, I see TMQL
> more in that light. I see TMCL as a binding of TMQL expressions into
> what can be called a constrint. something like :
>
> tmcl expression : Given the thing at [tmql expression] the thing [tmql
expression] must be > 1.

OK, my naming is simply the other way round:

   given [ tmcl-expression-characterising-situation] then [
tmcl-expression-characterising-other-situation ] must be fulfilled

But it is true that the [ ... ] expressions will also appear in a tmql
statement.

I would vote for allowing the query language to _also_ generate
content. Similar to SQL which reads tables and generates tables and
XQuery which reads XML and generates XML, I would find it nice it TMQL
would use a pattern detection language like TMCL to find particular
situations/constellations in a map and then generate content.

Whether this is TM content (which could be elegantly accessed via SAM)
or whether we allow XML to be generated is a different story.

> I agree that I am looking purely in terms of TM constructs. But isnt
> that the point, anything built on top of the TM constructs must be
> able to use tmcl and tmql to access and constrain that
> 'application'. So concretely, your constraint above can be
> formulated in terms of tmcl/tmql basic constructs.

> (given x (where (x playsrole 'teammember')) (implies (x employedby_company y)
AND (#y > 0)

But here you are NOT just looking at TM constructs only. You also look
at the TM from a 'global' perspective. You use quantifiers and logical
dependencies to express your constraints. You are basing this on the
TM constructs and then you are connecting that into a bigger
statement.

I think this is exactly where we should go, in fact your statement
above could be transformed into

    forall [ (*)
             teammember : $x ]
       => exists [ (employedby_company)
                   * : $x               ]

So I simply misinterpreted your earlier "TM-construct-based only".

> Having looked and thought about this some more I really dont think
> we can decouple tmcl from tmql. Otherwise we'll end up with the W3C
> XPath and whatever the other thing they used to have before they
> merged them.

Yes, I think we really should learn from this lesson. Changing things
like XPath once it is in production is a major PITA which we cannot
afford.

\rho

> -----Original Message-----
> From: Robert Barta [mailto:rho@...]
> Sent: 30 January 2003 04:55
> To: tmcl-wg@yahoogroups.com
> Subject: Re: [tmcl-wg] TMCL User Requirement #1: Please Comment
>
>
> On Tue, Jan 28, 2003 at 08:51:50AM -0000, Graham Moore wrote:
>
> > I think we are creating a langauge with which it is possible to
> > define constraints on a topicmap model. Specifically these
> > constraints define what 'topic map instance elements' are allowed in
> > a conforming map. 'topic map instance elements' are defined as the
> > specific topics, names, associations that are present in any given
> > map.
>
> ...and also rules about particular constellations of these, like in
>
>   "every project must have at least one project manager"
>
> > Perhaps it is more appropriate to state that we are defining a Topic
> > Map Schema and Constraint Language. Schema implies
> > templating/prototyping but does not necessarily requires validation:
>
> > example : I can define a schema to have 4 topics types and 3
> > association types/templates but that doesnt mean that every topic in
> > a map MUST have only these types and when it does it must comply to
> > the 'shape' of each of these.
>
> That's right, schemas/templates themselves are a rather weak form for
> 'constraining'.
>
> > It is necessary to make this distinction as some applications MAY
> > wish to use schema information in order to create a UI that can
> > guide the user in creating a map but doesnt stop them doing things
> > if they really want.
>
> Want what?
>
> I guess you are talking about form generation and what XML Spy does
> with DTDs/Schemas?
>
> > With regard to validation:
>
> > We should be stating what it is to be valid against a given
> > constraint/ set of constraints. We should not be stating when these
> > constraints are applied . This allows different implementations to
> > provide different levels of support.
>
> Nod.
>
> If we assume that a set of constraints is fulfilled when ALL members
> of the sets are fulfilled (implicit AND), then we can also break it
> down to the level of a single constraint.
>
> > These distinctions provide us with different levels of conformance/
application:
> >
> > a strict validating topic map application MUST ensure
> >  - that only instances of schema constructs exist in the map, i.e. only
topics of types defined in the schema can exist
> >  - that all constraints defined are conformed to in the topicmap
> >
> > a validating topic map application MUST ensure
> >  - that any structure that can be constrained conform to the constraints of
the schema.
>
> >  - i.e. if the schema defines a type called 'person' and the
> >         constraints say that an instance of person must have at least one
> >         name in the scope of 'surname' then a non-validating application MAY
> >         process the schema and use this information to help topic map
> >         authors to construct more consistent maps.
>
> I have difficulties getting this into my head? Why should we have
> two different conformance levels?
>
> > 1. That the language is expressive enough to allow any 'topic map
> > instance element' to be constrined. i.e. not just topics and
> > associations, but names, resource references, variants etc.
>
> And combinations of them, yes. Example:
>
>   "for every topic of type student there must be another topic of class
>    guinea-pig"
>
> > 2. Given (1) TMCL should/could use TMQL to locate the item to be
constrained.
>
> Or - the other way round - TMQL could use TMCL to identify particular
> situations and the task of TMQL is only to generate output.
>
> My understanding is that TMCL is something like XPath which is good to
> identify particular situations in a map. XQuery uses XPath to generate
> output with the content matched.
>
> In any case the languages overlap.
>
> > 3. As stated by others - TMCL needs to be easy for people to process.
>
> OK, but this is difficult to formalize.
>
> ...
>
> > 5. As part of the TMCL langauge we need to define the operational
> > semantics of validation and perhaps a set of Validation
> > Exceptions. I dont mean this in a strict programming fashion, but
> > things like : Cardinaltiy Exception, Type Exception. Constraints and
> > validation imply that exceptions will occur and we should consider
> > standardising these exceptions. As for the operational semantics, we
> > shoudl look to define how constraints are evaluated. This will
> > probably be done in terms of the operators we define in the
> > langauge. i.e. Cardinality of BaseNames of Topics of Type 'Person'
> > >= #1. This case is trivial and the behaviour of validation doesnt
> > need much explaining but I feel we must be careful not to leave
> > semantic holes in the kinds of operations we define otherwise
> > different maps could validate differently against different
> > implementations.
>
> Question 1: Why 'operational'? If it is about "does a map conform to a
> particular constraint?", then an operational semantics might be much
> more difficult to define than a declarative semantics.
>
> Question 2: I sense that you are only looking at constraints from a TM
> perspective, i.e. what kind of elements you find in a map.  If it is
> only that, then we could try to constrain the manifestations of
> basename, occurrences, associations ... and their cardinality.
>
> But what about "application specific" constraints such as
>
>    A: Every team member must be employed by a company (Somewhat arbitrary)
>
> Constraints like these _use_ only the concepts of TMs to convey the
> intended meaning. The constraint is not about one (or more) instance
> elements alone.
>
> \rho
>
> To unsubscribe from this group, send an email to:
> tmcl-wg-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
> _____________________________________________________________________
> This message has been checked for all known viruses by Star Internet
> delivered through the MessageLabs Virus Scanning Service. For further
> information visit http://www.star.net.uk/stats.asp or alternatively call
> Star Internet for details on the Virus Scanning Service.
>
> _____________________________________________________________________
> This message has been checked for all known viruses by the MessageLabs Virus
Scanning Service.
>
> To unsubscribe from this group, send an email to:
> tmcl-wg-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

At 12:12 03/01/31 +0000, Anthony B. Coates wrote:
>** Reply to message from "Rath, Holger (empolis KL)" <holger.rath@...>
>on Fri, 31 Jan 2003 13:01:05 +0100
>
> > But the tm?l wg lists have a different purpose. We want to
> > be as open as possible to involve interested and interesting
> > people. So visibility is an issue. And I think XML hack will
> > give us more visibility.
> >
> > So I vote for XML hack.
>
>I agree with Holger, and vote for xmlhack.
>
>         Cheers,
>                 Tony.

Also in agreement for the same reasons.

-- Mary

I am in agreement with this argument to. Extra visibility will help the
process.

+1 for xml hack

Kal

At 12:12 31/01/2003 +0000, Anthony B. Coates wrote:
>** Reply to message from "Rath, Holger (empolis KL)" <holger.rath@...>
>on Fri, 31 Jan 2003 13:01:05 +0100
>
> > But the tm?l wg lists have a different purpose. We want to
> > be as open as possible to involve interested and interesting
> > people. So visibility is an issue. And I think XML hack will
> > give us more visibility.
> >
> > So I vote for XML hack.
>
>I agree with Holger, and vote for xmlhack.
>
>         Cheers,
>                 Tony.
>====
>Anthony B. Coates, Information & Software Architect
>mailto:abcoates@...
>MDDL Editor (Market Data Definition Language)
>http://www.mddl.org/
>FpML AWG Member (Financial Products Markup Language)
>http://www.fpml.org/
>
>To unsubscribe from this group, send an email to:
>tmcl-wg-unsubscribe@yahoogroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/