[sc34wg3] TMCL: 4.4.1 Topic Type Constraint

[Robert Barta]

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/