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

Hi Lars,

On 5 Mar 2011, at 10:10 AM, Lars Heuer wrote:

> Hi Andrew,
> 
> [...]
>> 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.
> 
> The counter-argument is that supertype-subtype and type-instance
> relationships are one of the key-concepts in TMDM/TMRM. Breaking the
> semantics would be wrong. It is not just one axis where we'd break the
> semantics but a lot more queries would break.
> 
> Take our DBpedia astronaut example:
> 
>   astronaut ako person.
>   neil isa astronaut.
> 
>   select $x where $x isa person
> 
> "neil" wouldn't be part of the result set. Wouldn't that be strange
> given what's said about supertype-subtype/type-instance relationships
> in TMRM/TMDM?

What I'm suggesting would work with that query and do what you'd expect.  Now that I'm seeing more examples, I think the biggest differences in perspective between me (apparently the minority) and the rest of the voices on this discussion is that I would see isa as an overloaded operator (at least x2) rather than an axis.

In my earlier example and in the example above, there's two different ways of decomposing the query into actual map/graph operations.  I don't want to argue about which is better, but just to illustrate them.

One approach (and this is the one I see implied by the majority) is that the steps would be:

	forall x where x is of type person or any subtype, print x

Another approach (based on isa being an operator, not an axis and having equivalent semantics to #instanceOf (Java) or #is_a? (Ruby)

	forall x print x if x is a type of person or any subtype

The second way isa is overloaded is in assigning explicit types to topics, e.g.:

	x isa person.

Again, I think this is straightforward.  I would assume that this makes x an instance of person, not any and all possible subtypes of person, right?

If I was interested in a set/bag-based view of the graph, then I would use the path navigation/selectors (names for illustration only)

	x // type => the set/bag of all the parent types of x

or

	x / type => the set/bag of all the explicitly assigned types (e.g. direct types) of x

Again, just to be clear, I'm not talking about changing the semantics of transitivity of TM, I'm just talking about the distinction (in my view) of the isa operation vs the type axes.

You guys that have been on the TMQL train a while may not see isa as an operator, but I doubt I'm the only one who would.  Even though I've been through the TMRM many times and been building software based on it for over 4 years, I still have this distinction in my head.  Maybe that's operator error on my part or due to early misunderstandings of the TMRM.  However, I do see 'isa' as either an assignment operator or as a boolean check operator rather than a selector.  I think that's the biggest difference between the perspective I'm describing vs. what you guys are saying.

Either way, I still don't see them as incompatible.

Cheers,

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