Standards » CTM

IMO the spec should clarify that the test case is correct.

Reason: It is allowed to pass an IRI to a template and it's interpretation is context-dependent. I.e.:

def tpl($iri):
    $iri homepage: $iri.

    assoc(type: $iri)
end

or:

def tpl2($iri)
    topic $iri; homepage: $iri.

    assoc(type: $iri)
end

Here, we interpret the $iri either as literal with the value $iri^^xsd:anyURI or as topic or as subject identifier. Wouldn't it be counter intuitive if we'd interpret =<IRI> always as topic reference?

I think the spec should be fixed, not the test case. Thoughts?

If we look at the grammar for topic invocation it says that a parameter must be either a topic reference or a literal. It makes sense to interpret this as the parameter value being either a topic or a literal.

The subject identifier case is special because there's no way to distinguish syntactically between iri-as-si and iri-as-iri in the invocation. This can only be done where the parameter is used.

The subject locator (and item identifier) case is different, because here it is clear syntactically what we are seeing is a subject locator reference. To me it seems that you want to say that "a subject locator topic reference can be interpreted either as a topic reference or as a subject locator assignment".

To me that seems illogical and unnecessarily complicated. We could amend the spec simply to say that parameters are passed by value, so that a topic reference parameter passes the topic and literals pass the literal. A little extra verbiage is needed to cater for the iri-as-si case, but other than that it should be straightforward, both conceptually and in the spec.

Personally, I like that feature and I don't find it very complicated / unlogical.
Anyway, this feature is not that important so I'll rethink it.

We might invite a third opinion, too.

In reply to http://www.isotopicmaps.org/pipermail/sc34wg3/2010-January/004409.html:

Lars Marius Garshol wrote:

Here the parameter is interpreted as a topic referred to by its subject locator. Obviously fine. But what about this? (And please don't be confused by the name of the template.)

foo has-psi( = http://example.org/some-resource ).

Is this an error because we are passing a topic to $psi, which cannot be a topic because of how it's used inside the template, or is it OK because we're really passing a subject locator assignment, so that > it becomes equivalent to:

foo = http://example.org/some-resource .

I think we should only be able to pass URIs, Strings or Topics but not "subject locator assignments" to templates. However, I'm sympathetic to the idea to allow two topics to be referenced within the same topic-syntactic-construct (e.g. within the expression of http://www.isotopicmaps.org/ctm/ctm.html#sec-topic ). This way,

foo has-psi( = http://example.org/some-resource ).

would be interpreted as

some_arbitrary_topic
  = http://example.org/some-resource
.

foo has-psi( some_arbitrary_topic ).

but for a template defined as

def has-psi($t, $topic)
  $t $topic .
end

foo has-psi( some_arbitrary_topic ).

• unambiguous
• and still does what would be naïvely be intended.

I have to admit that I don't understand your comment (are you pro foo has-psi( = http://example.org/some-resource ). or against it?), but I want to emphasise that we do not pass a "subject locator / item identifier assignment" to templates but a subject locator / item identifier. The "assignment" happens within the template. At least this is my understanding.

Lars Heuer schrieb:

... I want to emphasise that we do not pass a "subject locator / item identifier assignment" to templates but a subject locator / item identifier...

This sounds like it might be an important point. What is it you do consider that we are passing? I mean, there's no such thing as a subject locator in the TMDM. There are locators, and there are topic items with [subject locator] properties, but subject locators as first-class citizens don't exist.

FWIW, I didn't understand Xuân's comment either.

What is it you do consider that we are passing?

Well, maybe contrary to TMDM, a subject locator (or item identifier, subject identifier).

I mean, there's no such thing as a subject locator in the TMDM

TMDM says: subject locator: locator that refers to the information resource that is the subject of a topic

You're right, that TMDM treats every locator equal and once it is added to the [subject locators] property, it is interpreted as subject locator, but CTM has an explicit notation for subject locators (and item identifiers), so I think it's legal to pass these things to templates.

I agree that passing "assignments" is strange, but in my view we don't pass assignments but a locator that is either a subject identifier, subject locator or item identifier.

To the question "Should

def template($foo)
    topic $foo .
end
template(= <http://www.example.org/>)

To the question "Should template parameters be of any other type than topic types or literals (IRIs, strings, numbers, dates, ...)?" I say "No. Especially subject identifiers, subject locators, item identifiers should not be able to be passed as such as template parameters.".

• interpreting the parameter of this template invocation

  template(= <http://www.example.org/>)

  to be of type topic and
• by interpreting

  topic $foo .

  (where $foo is of type topic) as instruction take topic "topic" and the topic "$foo" and merge them together.

This way, the CTM author can build partial topics independently of each other (e.g. automatically) and merge them later by a simple template like the example above, or like

def merge($bar,$foo)
  $bar $foo .
end

Simply replace "identity" by "topic-ref" in the list of alternatives of the "topic-tail" production (http://www.isotopicmaps.org/ctm/ctm.html#topic-tail), and that's it. :-)

Xuân:

Simply replace "identity" by "topic-ref" in the list of alternatives of the "topic-tail" production

Well, then we'd also allow:

1.
identity1 identity2 identity3.

2.
identity1 [- "Name from the embedded topic" [-"Another embedded topic"]].

Unaesthetic, IMO.