[sc34wg3] Illustrating SIDPs

[Robert Barta]

On Sat, May 08, 2004 at 01:15:48PM -0400, Patrick Durusau wrote:
> Dmitry wrote:
> >
> >On May 4, 2004, at 2:30 PM, Patrick Durusau wrote:
> >
> >>SIDPs (and, for that matter, OPs) can be arbitrarily complex.
> >>
> >
> >That is what I cannot find in current TMRM. I see that SIDP can be 
> >defined as "combination of properties"  which I cannot call "arbitrarily 
> >complex".
> >
> 
> Why did you decide that "combination of properties" does not equal 
> "arbitrarily complex?"
> 
> Would you prefer "arbitrary combination of properties?"
> 
> Curious because that "combination of properties" is understood (by me at 
> any rate) to mean "arbitrarily complex."

Patrick,

Obviously we reach here an area where - without more formalisation - confusion
is imminent.

If I hear "arbitrary combination of properties" then I would think that there
are properties p1, ..., pn and the combination is defined as function f operating
on these properties, returning a new, combined 'property':

   p_new = f (p1, ..., pn)

In your earlier example f would simply concatenate two existing properties
of a topic:

> >     * Property name:              "personID"
> >
> >     * Value type:                 complex:
> >                                      "name"   : string
> >                                      "spouse" : topic
> >
> >     * SIDP or OP?:                SIDP

So the equivalence is induced by the function values which are built
from - more primitive values. This is all good and well, but...

> Dmitry said:
> >TMCL on the other hand can express any equivalence function. I just 
> >think that TMCL is more general and powerful approach for defining 
> >equivalence classes. "Combination of properties" is a subset of possible 
> >equivalence functions.

...with functions over topic properties (and the primitive identity on
symbols =strings)) you cannot handle application-specific constraints
as TMCL would allow you to:

What about an identity which is induced by the fact that two topics
should be regarded the same if both are "involved in the same kind and
number of criminal activities"? (Not saying that TMCL should be able
to capture this!)

TMRM is 'property' oriented. That is nice and easy for many cases, but this
cannot be regarded as 'arbitrarily complex'.

Now, ....

> There is no other hand. The TMRM and TMCL are addressing completely 
> different levels of the topic map paradigm.
> 
> The TMRM is not defining a syntax but the rules for a disclosure 
> statement, on which a syntax would be based.
> 
> In other words, the TMRM allows disclosure of the basis for identity 
> that must underlie any equivalence or other functions.

... of course you say that. But to me this sound as saying "the nice
and easy things we can capture with properties and functions on
properties - while we do not say how it is done" and "the other stuff
is done with TMCL".

>From an standard engineering point of view one might argue that there
is so much overlap in the task to define an identity concept, that it
is worth exploring the redundancy.

Now, the fact that TMCL is obviously going to be well-founded and uses
a more formal, explicit way to impose structural constraints on maps
(and identity is just that) might raise the question how TMRM fits
into the picture.

> Mixing levels again. The TMRM, using SIDPs, enables the disclosure of 
> identity that must be present for any such rules to make sense. And yes, 
> you can then disclose the equivalence (or any other rule) that you like.

I think what Dmitry is after (and I would support that) is that
identity at the most fundamental level is simply done by the identity
of symbols, so strings, and the derived ones on URIs. From that you
would derive identity based on source location, etc.

Yes, you are right that we are mixing levels, i.e. using TMCL now for
parts where TMRM has put in a claim. Maybe it is TMCL which has to be
at two levels:

  - level one as a language to define 

    - what actually properties are in terms of associations. So, for
      instance, a property 'email'

      $t.email   <=>    $t -> entity \ has-email-address / email

      (saying that any topic which is involved in a 'has-email-address' association
      with the proper roles can be regarded to have an 'email' property)

    - what derived properties are:

      $t.age           <=>   now - $t.born

    - what derived identity can be:

      ident ($a, $b)   <=>   $a.email eq $b.email

    - what identity can also be:

      ident ($a, $b)   <=>   ...

  - level two captures the other things covered in the TMCL use cases.

[ Merging is handled in general as a function M which maps map1, map2 into maps.
This could be TMQL, btw. ]

> But wait:
> 
> P1 (carol (wife of patrick), bambi (deer in Walt Disney movie), clarence 
> (patrick's dog), and
> 
> P2 (carol (as to sing), bambi (a stripper), clarence (ghost in "It's a 
> Wonderful Life," a movie).
...
> Answer: Well, TMCL presumes a doctrine of identity (that should be 
> defined elsewhere) that allows it to make meaningful comparison of the 
> members of each ordered set.

Yes, and this doctrine can be that of string equivalence.

> The notion that identity and doctrines of identity can be
> assumed/presumed is quite surprising to me .....

That is not what I (or also probably Dmitry) say: My conjecture is
that we can found ALL concepts eventually on the identity of
strings.

\rho