Re: TMQL: Direct (super|sub)types?

Hi Robert,

On 5 Mar 2011, at 8:53 AM, Robert Barta wrote:

> On Sat, Mar 05, 2011 at 12:20:11AM +0100, Benjamin Bock wrote:
> 
>>> I think there will be a need to distinguish between direct and all instances of a topic type. I can hardly imagine a use case case for indirect but who knows. I think the TMQL standard is the right place to establish a clear terminology for this distinction since everybody tackles this issue a little bit different. Some call it "direct" or "deep" or whatever.
>> 
>> Another name would be "transitive" (even though the transitivity comes
>> from the supertype/subtype, not from the type/instance itself. When
>> you do topic-maps-object-mapping (as in object-relational), you'll see
>> a lot of cases where you want the transitivity.
>> No matter how it is called.
>> 
>> The "direct" is due to the fact that the transitive axes should (IMHO)
>> be the default.
> 
> I strongly would agree with that. The *canonical* use case is:
> 
>  One has an TM-app which is using a background ontology. It works.
>  Customer refines the ontology and introduces intermediate types on a
>  Fri night.
> 
> - subclass transitivity: no change, you sleep through the weekend
> - no transitivity: shit hits the fan, wife angry, programmer pissed


I think this is one of the weakest use cases I could possibly imagine for having the default pull all subtypes.  If you don't care, then you should defensively make that distinction on the areas of the code, the ontology and the domain in which you have control.  If you do care (as I think most of the "mainstream" programming community you mentioned later would), then I think "breaking" in this case is exactly the right thing to do.  If you didn't care, then you should've indicated you didn't care at the implementation time.

I think the biggest thing in my mind here is the context of use.  To me:

	if (t isa x) then
           ...do something if t is a direct or indirect subclass
        end

is a vastly different scenario than using

        for x in ( x // types ) do
            ..do something for each match for the entire tree
        end

From the discussion, I see the two usage contexts overlapping.  For the "mainstream programmer" argument (of which I guess I'm one), would expect to be able to use those type of semantics in solving the problem.

I'm not saying that TMQL shouldn't be based on a formal model with consistent semantics, but I think I'm a bit confused from the use case as to whether it's supposed to be a scripting language on its own (supported by CTM and TMCL) or whether it is expected to be mixed in or used from host languages.

Even if TMQL is intended to be a scripting language a la SQL stored procedures, you still have contextual semantics of operators, so I still don't see why the above is an issue.  I guess I'm just being thick...

Cheers,

ast
--
Andrew S. Townley <[email protected]>
http://atownley.org