Re: TMQL - Proposal: Removal of reifier axis

On 1 May 2011, at 9:13 PM, Lars Heuer wrote:

> Hi Andrew,
> 
> [...]
>> The main problem I see is that your proposal makes subject proxies
>> in the general sense first-class citizens in the TMDM. Once this
>> happens, there's no longer a need for the distinction of constructs
>> that can only have terminal property values (TMDM topics) and
>> constructs that can only have non-terminal property values - what I
>> call links (TMDM associations).  This would therefore invalidate a
>> number of fundamental assumptions baked into TMDM systems, and I
>> think that makes it a non-runner (in addition to rather unpopular). ;)
> 
> I know what you mean but I don't want to make constructs != topic
> first-class citizens in TMDM (not yet ;)). TMDM wouldn't change, we'd
> just define that TMQL supports a more truthful model and supports
> reification directly. I don't know if that works or is accepted (I am
> afraid it won't). TMDM, XTM, TMCL and CTM would stay as they are (an
> explicit reifier property) but TMQL would interpret reification
> correctly.
> 
> TMDM systems (like TMAPI) wouldn't break, I think. If a TMDM system
> sees a query like
> 
>     $name/role[. isa foo]
> 
> it would check if the name is reified and iterate through the played
> roles of the reifier. If the name is not reified, the sequence would
> be empty.
> 
> Maybe TMDM addicts would be surprised if
> 
>    $name/type
> 
> returns a sequence with more than one item iff $name is reified and
> the reifier is an instance of another topic, but TMQL wouldn't unhinge
> TMDM. TMQL would just provide a more truthful interpretation of TMDM. ;)


Yes, I think this makes sense as a first step if you're just talking about behavior within the TMQL environment.  As TMQL is really the first explicit bridge between the TMDM and the TMRM, trying to clarify the behavior of the boundary cases of the TMDM with expected behavior in TMQL seems a good place to do it.

I was looking a bit past this towards impacts on the underlying model and implementations thereof, which probably wasn't a good idea.

Cheers,

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