[sc34wg3] TMCL: 4.4.1 Topic Type Constraint

Graham Moore gra at networkedplanet.com
Thu Feb 14 07:13:13 EST 2008


>> Is this statement part of the original map? Probably not?
>> Is this statement part of the schema? Maybe.
>> But then TMCL has to say somewhere that the TMQL expression (or
actually
>> the whole validation is done on the merge of
>>   original_map + schema

My expectation has been that a schema CTM document contains normal ctm
statements and uses the templates provided by tmcl.

So 

Person isa tmcl:topictype
       occurrenceConstraint(age, 1, 1)
	 nameConstraint(pseudo, 1, 1)

TMCL says that for a given constraint and a map the outcome is true or
false.

Given that the constraints themselves are topics in the map, and that
the schema is a topic then how it actually all got into the map doesn't
matter. 

Validation takes the map and for a specified constraint, or all
constraints of a identified schema validate.

So, in short, it's the authors responsibility to ensure that topic types
are marked as such.

Also: you don't have to have the topic of type constraint in your
schema.

And... 

If a processor wants to keep a set of constraints separate and merge
them in right before validation, it can do. 


--------------------------------------------
Graham Moore, Director, Networked Planet Limited
Editor XTM 1.0, ISO13250 (TopicMaps) -2,-3, TMCL
e: graham.moore at networkedplanet.com
w: www.networkedplanet.com
t: +44 1865 811131 
m: +44 7769658611 (UK)
m: +47 45271713   (Norway)

Networked Planet Limited is registered in England and Wales, no. 5273377
 

-----Original Message-----
From: Robert Barta [mailto:rho at devc.at] 
Sent: 14 February 2008 12:35
To: Graham Moore
Cc: Discussion of ISO/IEC 13250 Topic Maps
Subject: Re: [sc34wg3] TMCL: 4.4.1 Topic Type Constraint

On Thu, Feb 14, 2008 at 10:21:32AM -0000, Graham Moore wrote:
> 
> A couple of things...
> 
> >> We still have to say something about making the fact
> >>     Person isa tmcl:topicType
> >> accessible to the TMQL processor which effectively checks the map.
> 
> This fact should have been stated by the author of the map.

Is this statement part of the original map? Probably not?

Is this statement part of the schema? Maybe.

But then TMCL has to say somewhere that the TMQL expression (or actually
the whole validation is done on the merge of

    original_map + schema

> >> uniq ( // tm:topic >> types ) -- // tmcl:topicType == null
> 
> This looks good, just to clarify, this says that the set of topics
that
> have instances and are not of the type topic-type is 0?

Yes:

// tm:topic       # find all instances of topics (so no assocs, occs,
...)
       >> types   # find from there all their types, direct or indirect
uniq ()           # make sure that we remove all the duplices

// tmcl:topicType # find all those which are marked as topic Types
   --             # this give only those which are used as type, but are
not
                  # ear-marked

  == null         # we do not want this 'set' to be non-empty

\rho


> -----Original Message-----
> From: Robert Barta [mailto:rho at devc.at] 
> Sent: 14 February 2008 09:38
> To: Graham Moore
> Cc: Discussion of ISO/IEC 13250 Topic Maps
> Subject: Re: [sc34wg3] TMCL: 4.4.1 Topic Type Constraint
> 
> On Thu, Feb 14, 2008 at 07:40:53AM -0000, Graham Moore wrote:
> > >> How is 4.4.1. to be understood? 
> > >>  "..only topics  ... defined as topic types can have instances"
> > >> What about association types, occurrence types and name types?
They
> > >> definitely need to be "topics allowed to have instances".
> > 
> > Firstly, this is a map wide constraint.
> 
> Yes, many constraints in TMCL are map wide.
> 
> > It is trying to say that if a topic plays the role of type in the
> > type-instance association and it is NOT an instance of the topic
> > tmcl:topic-type that the given type topic violates the topic type
> > constraint. 
> 
> > .... The evaluation function knows the topic of topic-type (its
> > defined in TMCL) and can thus derive the list of all topic types at
> > evaluation time.
> 
> Hmm, 4.1. says that "Constraints are independent from each other....",
> but obviously TMCL somehow makes a distinction between allowing to say
> 
>      "Person isa tmcl:topicType"
> 
> and the actual TopicTypeConstraint which is sort-of hovering in the
> background. I didn't get this from the text. But my interpretation
> 
> >   uniq ( // tm:topic >> types ) -- // tmcl:topicType == null
> 
> would then reflect this. Good.
> 
> > I'm not sure I follow the bit about having to adopt the tmrm-tmdm
> > mapping stuff. TMCL aims to be self contained in terms of TMDM and
> > TMRQL. Given we can identify the topic-type topic we don't need the
> > tm:topic in order to formulate the query.
> 
> Well, TMQL _has_ to use TMDM and needs hooks to get access to the
> innards of a map.
> 
> > Hope this starts to clear some things up.
> 
> We still have to say something about making the fact
> 
>      Person isa tmcl:topicType
> 
> accessible to the TMQL processor which effectively checks the map.
> 
> \rho
> --
> Austrian Research Centers, Environmental Monitoring Systems
> http://www.smart-systems.at/rd/rd_environment_en.html
> 

-- 
And then he said: "You should read my blog." http://kill.devc.at/


More information about the sc34wg3 mailing list