[sc34wg3] Subordinate clauses

[Xuân Baldauf]

In my work for creating CTM documents as a means to collect information
in an ad-hoc manner, I almost always want to write down the source of
the information I got. I do it like this:

    john
      - "John Lennon"
      works_for({the_beatles
        - "The Beatles"
        isa music_group
      })
      died_in(new_york) ~{?
    source_resource("http://news.bbc.co.uk/onthisday/hi/dates/stories/december/8/newsid_2536000/2536321.stm")
    }

Verbally, this means:

    John Lennon, who worked for the music group "The Beatles", died in
    New York, according to the resource
    "http://news.bbc.co.uk/onthisday/hi/dates/stories/december/8/newsid_2536000/2536321.stm".

Now try to convert this to one of the recent CTM notations:

    john
      - "John Lennon"
      works_for(the_beatles)
      died_in(new_york) ~random_topic_654166

    the_beatles
      - "The Beatles"
      isa music_group

    random_topic_654166
     
    source_resource("http://news.bbc.co.uk/onthisday/hi/dates/stories/december/8/newsid_2536000/2536321.stm")

I think the latter notation (be it pre- or post-Kyoto) has certain
disadvantages:

   1. It takes 11 lines instead of 7 lines while providing not more
      information.
   2. It is harder (and takes longer) to read in human language (at
      least in my languages). In this sequence, it would read like “John
      Lennon worked for The Beatles and died in New York. The Beatles is
      a music group. That John Lennon died in New York, this is
      according to the resource
      "http://news.bbc.co.uk/onthisday/hi/dates/stories/december/8/newsid_2536000/2536321.stm".
      ”
   3. It forces the author to invent an ad-hoc random, but unique, topic
      identifier, while the topic identifier is of no meaning or purpose
      for the author. Being forced to generate a unique topic identifier
      is quite a hard task. It takes longer then devising a password.
      Try to devise a password nobody would be able to guess, and then
      ensure that it is different from all the other passwords you have.
   4. Information belonging semantically closely together is spread out.
      This makes the document less readable, less changeable and harder
      to understand its meaning. This effect is even worse when having
      multiple sources of information for one topic.


This is why I would like to have subordinate clauses in CTM. For me,
having subordinate clauses or not in CTM makes a difference like having
closures in a programming language or not. However, I do not care about
the exact syntax.

I see that others have the same idea:

    * Robert Barta wrote:
>       [...]
>>       N3 is a good example of how nesting can help to define complex
>>       structures in a compact form without additional mechanism for
>>       templates.
>>               
>
>       I agree, and that is also where AsTMa= is going. Effectively,
>       everywhere where a topic id is allowed, a fully-fledged topic
>       definition can be.
    * Dmitry wrote:
>       [...]
>       I would prefer it this way:
>
>       paul
>            ~ o:Paul_McCartney;
>            # <http://....#Paul_McCartney>;
>            - "Paul McCartney";
>            first_name - "Paul";
>            last_name - "McCartney";
>            isa person, musician;
>            o:works-for    [o:The-Beatles - "The Beatles], o:The-Wings;
>            o:homepage  <http://www...>
>             
      Note the “[o:The-Beatles - "The Beatles]” (which, by the way, has
      an unmatched double-quote, it should read as “[o:The-Beatles -
      "The Beatles"]” I suppose). Apparently, the “[o:The-Beatles - "The
      Beatles"]” is a subordinate clause, that is, a reference to a
      topic while explaining a little bit about that topic.

Do you think that having subordinate clauses in CTM is a good thing?

ciao,

Xuân.

P.S.: Note that this is no proposal in favor of a "{}" vs. "." syntax.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.isotopicmaps.org/pipermail/sc34wg3/attachments/20080130/97a2099e/attachment.htm