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

On 3 Mar 2011, at 11:29 AM, Robert Cerny wrote:

> Am 03.03.2011 um 12:01 schrieb Andrew S. Townley:
> 
>> 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 could live with your last proposal as well. It's a tough call to decide which i like better. Probably a draw. I think most importantly the default should be the same over those four.

Agreed, and after I typed it, I think I'd be in favor of borrowing the XPath notation, e.g.
	
	s1 // types for all types,

	s1 / types for direct types

>> 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.
> 
> I find this difficult to judge. There is many schools of thoughts in information technology and they all leave quite strong marks in the minds of their followers. So sometimes what is obvious to one is totally obscure to another.


A valid point, but I'm also trying to be pragmatic here too.  TMQL and Topic Maps aren't the only technologies with path languages, and there's a lot more users of XPath (for argument's sake) than there are of topic maps.  And if the notation was something like the above, you're talking one extra keystroke and a pretty clear way to explain how the behavior has been modified.

I'm sure you'll immediately have one in mind ;), but you don't generally see modifiers used to restrict the extent of an operator.  Normally, it's to relax constraints, not add them.  That's really the basis where I'm coming from here.

To Rani's comment:

On 3 Mar 2011, at 11:48 AM, Rani Pinchuk wrote:

> Actually, it will be pity if this will be the default behavior as this will not be inline with TMDM.
> 
> If we take the following example:
> 
> Tosca -> Opera -> Musical Work -> Work
> (that is, Tosca is an instance of Opera. Opera is subtype of Musical Work. Musical Work is subtype of Work).
> 
> We have here two needs:
> 1. Getting the language to work according to the semantics as defined in TMDM (where supertype subtype is transitive relationship). That is Tosca is instance of Opera, but also of Musical Work and of Work. Opera is subtype of Musical Work but also of Work.
> 2. For some use cases, we need to know the direct type or supertype.

I don't see how we're breaking the transitivity here at all.  It's quite clear that all of

	Tosca isa Opera
	Tosca isa Musical Work
	Tosca isa Work

should all be true.  The question is related to the selector for the axes, right?  We're not talking about changing the transitivity.  I would see "isa" as an operator, not an axes in this context.

> On 03-Mar-2011 12:01, Andrew S. Townley wrote:
> > 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
> 
> How would you call this axis which gives one level only? If you do not include the word "direct" (or something similar), you practically confuse the users: when we ask for "instances" of Work in the above example, we will get nothing - as Tosca is a direct instance of Opera and not or Work. But according to TMDM Tosca is one of the instances of Work. How should we call this one level axis then?
> 
> So I think the default behavior should be according to TMDM.

Actually, I'd expect
	
	Work / instances => []

and I'd expect 

	Work // instances => [ Tosca ]

As per above, I would also expect to be able to introspect Tosca as follows:

	Tosca isa Work => true
	Tosca / types => [ Opera ]

I don't see how you would confuse "the users" for "the users" at large who are familiar with classic typing/inheritance behavior.  What am I missing here?  I'm not being cheeky, I really want to understand why something like the above is a core problem and is fundamentally incompatible with TMDM.

Cheers,

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