[sc34wg3] TMCL: 4.4.1 Topic Type Constraint

Robert Barta rho at devc.at
Thu Feb 14 09:49:16 EST 2008 

On Thu, Feb 14, 2008 at 01:27:32PM -0000, Graham Moore wrote:
> 
> >>   (a) MUST merge them,
> 
> Defn a) is implied, but only for the purpose of validation. It
> doesn't actually modify the map being validated.

Sure, but TMCL never says that. I think it should, otherwise it leaves
the TMQL-induced semantics in the air.

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

Yes:

   http://kill.devc.at/system/files/tmql.html#ItemReferences

4.3 Item References

  2) If the item reference is a QName, then first that is expanded
     into an absolute IRI according to 4.2. That absolute IRI is
     interpreted as subject indicator for a topic in the effective
     map. If no such topic exist, an error will be flagged.

\rho


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

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

More information about the sc34wg3 mailing list