[sc34wg3] TMCL: 4.4.1 Topic Type Constraint

[Graham Moore]

>>   (a) MUST merge them,

Defn a) is implied, but only for the purpose of validation. It doesn't
actually modify the map being validated. 

I would imagine a processor has a few different options (here are a
couple):

Validate(tmdm_instance, psi_for_schema_topic)
Validate(tmdm_instance, tmdm_schema_instance, psi_for_schema_topic)

But in all cases behind the scenes the schema map and instance map are
merged for validation.

Btw, in tmql, what happens if the topic for topic type isn't defined? An
exception?

Graham


--------------------------------------------
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 13:46
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 12:13:13PM -0000, Graham Moore wrote:
> 
> >> 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 far, so good.

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

This is part of the schema then.

> Given that the constraints themselves are topics in the map, ....

Uhm, that is my point: When does that happen?

> .............................................................and that
> the schema is a topic then how it actually all got into the map
doesn't
> matter. 

Oh.

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

Well, no. Because if we say in a TMQL statement (or whatever means),
_what_ precisely has to happen, then we have to commit ourselves where
the things for the {true|false} decisions are coming from.

So if we have there

   ... // tmcl:topicType

then the information _what_ instances are there effectively has to be
take from the schema. So if that AND the map are queried in one go,
then a processor

  (a) MUST merge them,

  (b) or we invent something else

\rho

> -----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/
> 

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