[tmcl-wg] Re: Selectors [was: Another TMCL use case]

[Robert Barta]

On Thu, May 22, 2003 at 12:27:17AM -0400, Dan Corwin wrote:
> * Robert Barta
> 
> >It cannot have the same semantics as putting it into the
> >context of a topic you drastically reduce the expressiveness.
> >What about a constraint
> >
> >  "for all topics which are cars and have a subject identifier
> >   pointing to http://...., this and that has to hold."
> >
> 
> Would this work okay?
> 
> <topic id="car">
>  <occurrence>
>    <instanceOf>
>      <topicRef xlink:href="#instanceCriteria" />
>    </instanceOf>
>    <resourceData>
>      if (si == "http://....") then [oc (model) : * ]
>    </resourceData>
>  </occurrence>
> </topic>

Yes, but this is just a different way to write

   forall [ * (car)
            sin : .... ]
     => exists [ oc (model) : * ]

If you want to have that XMLified, it is obvious how to write a
transformer once a parse tree exists:

  <a:forall xmlns:a="http://astma.it.bond.edu.au/ns/1.0/" xmlns:t="www.topicmaps.org...">
     <a:pattern open="yes">
        <t:topic id="*">
           <t:instanceOf href="#car"/>
           <t:subjectIdentity>
              <t:subjectIndicator href="..."/>
           </t:subjectIdentity>
        </t:topic>
     </a:pattern>
     <a:exists>
        <a:pattern open="yes">
           ....
        </a:pattern>
     </a:exists>
  </a:forall>

Oh, and BTW, this is called XAsTMa. :-)

> >I always wonder why people think that XML is the only
> >way to induce syntax into a text stream. People have written compilers
> >now for 50 years and have all used parser successfully. No programmer
> >would appreciate a programming language coded in XML.

> I agree 100%.  And I secretly hope you construct a compiler for
> AsTMa!, so it can be retained as the source code.

Of course this already exists.

> >I also have worries coupling a constraint too tightly with a map.
> >Technically these things are always separate: databases and their
> >schema, XML and their schema, RDF documents and their schema, ...
> 
> Actually, I worry about keeping them distinct.  They can get separated,
> then evolve out of sync.  But issue this is easy to resolve.

Probably. For OWL it was an explicit requirements that the schema is
completely detached from the information and this makes a lot of sense
to me. Only then schemas (or in our case ontologies) become a good by
themselves and are not so strangely tied to documents as DTDs. That
made a lot of mess.

And there are also quite a few application scenarios where the
ontologies MUST BE detached.

> If TMCL compiles a source into XTM schema, roughly as above, then your 
> output file can stay separate, and I can merge mine into my TM.

Well, nothing can stop you to copy an ontology into every document.
Whether this helps you to manage them in the long run you have to
design.

> >I SERIOUSLY doubt that code which iterates over all
> >topics just to check whether some constraint should be checked is
> >faster than one which implements indexes or some other way to be more
> >selective.
> 
> I would try to test with *no* iterating - see testProp().  The code
> just uses the engine API and its given args to look up what it needs.

Any application using a generic TM API MUST BE slower than an
(optimizing) validator, I'd assume.

> A TMCL compiler creating XTM schema can be coded in Perl and run across
> the net.  But if its run-time support module was also in Perl, then my
> Java app would be calling Perl code on its local host.  That interface 
> would make me very nervous.  At best, it is *not* platform portable.

I do not understand what Java and Perl have to do with TMCL. The only
thing which seems clear to me that for C programmers there will be a C
API, for Java guys a Java API and for adults Perl :-)

Whether the Java or Perl (or whatever) API makes use of a C API just
to speed up processing is not something which TMCL is concerned with.

> So I think we must require TMCL's interpreter to run in the engine
> process for speed and transportability.

You mean that a TMCL validator is embedded via a library (class in
Java speak)?  Yes, why not. Or as a separate process in a Topic Map
database? Yes, why not.  Or as a web service where someone sends XTM
and TMCL data and gets back a report like for the HTML/CSS validators? 
Yes, why not.

You see, there may be a lot of scenarios and all of them may make
sense under particular circumstances. The language designers have to
stay out of the way here.

> >I do not see a limitation yet in terms of use cases. Maybe you mean
> >here usage scenarios.
> 
> To me they mean the same.  Explain the difference; I'll adjust.  :->

For me a 'scenario' is more a full application, including a technical
scenario as such:

   - have 10000 topic maps
   - have 100 different ontologies
   - depending on the day of week different TMs have to be checked
   - have stored all in a TM backend database
   - can be checked offline (in the night as batch)

A use case for TMCL is:

   - have a particular application (literature references)
   - want to express that "every book must have an ISBN occurrence"

YMMV (Your mileage may vary).

\rho