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

Hi Andrew,

On Thu, Mar 3, 2011 at 12:01 PM, Andrew S. Townley <[email protected]> wrote:
>
> On 3 Mar 2011, at 10:41 AM, Robert Cerny wrote:
>
>> Am 03.03.2011 um 10:43 schrieb Lars Heuer:
>>
>>> Are we introducing a doubtful terminology/value?
>>
>> If TMQL does not introduce a terminology for the distinction, then something doubtful will arise because there *is* different ways how to tackle this issue. Whatever choice you make on the defaults you will have to support it with additional axis. Correct?  I like the approach the document [1] proposes. What is your alternative proposal?
>
> After a brief off-list discussion with Lars, I understand better the default behavior intended by the isa/types axes.  However, I think that introducing a direct-BLAH vs. BLAH named axes isn't really the right way to go, even though we need to support both use cases.
>
> One thing we need to do is make it easy for people to understand what the default behavior is and why it is that way.  This is true both for implementors, but also for people (the people out there who we would like to have as topic maps users) using the query language to build systems.  To ease the adoption, it should also, where possible, follow the conventions of other languages in terms of modifiers.
>
> The main question here, as Patrick summarized, is what is the default behavior of the types/supertypes axes.  If the default behavior of the axes is to only pull one level of inheritance, I still think that will have less surprises to users of TMQL than if they get all of the inheritance back as a bag of topics.  Notationally, it also means that expanding the default behavior of an axes to include more results can be easily represented with some kind of modifier.
>
> This approach is taken by lots of systems whether it's "/**/*" to match an arbitrary depth of filesystem paths to XPath's "//[expr]" to find nodes anywhere.  Why can't we leverage existing conventions here and say that the default behavior of the axes is to pull a single level, and then if a modifier is present, e.g. s1 / *types or s1 /*supertypes, then we pull the whole thing.
>
> I think the semantics of the notation would remain clear, all the use cases would still be supported and it would make more sense to more people.
>
> Has something like the above been considered previously?  If so, why was it rejected?

If you want to operate on the "raw data", the direct axes are the way
to go. If you want to operate on the intended meaning, the transitive
axes are the way to go. Having it transitive is like "instanceof" in
Java which differs to an == comparison with getClass().
Both ways are useful at certain times.

Cheers,
Benjamin

>
> Cheers,
>
> ast
> --
> Andrew S. Townley <[email protected]>
> http://atownley.org
> _______________________________________________
> topicmapmail mailing list
> [email protected]
> http://www.infoloom.com/mailman/listinfo/topicmapmail
>
_______________________________________________
topicmapmail mailing list
[email protected]
http://www.infoloom.com/mailman/listinfo/topicmapmail