[topicmapmail] LTM 1.3 Change Proposal
Lars Marius Garshol
larsga@ontopia.net
Tue, 04 Jan 2005 16:15:34 +0100
(Note: while this may look like a discussion between Steve and me,
this email is really a summary of the discussions we had at an
internal Ontopia meeting today. So Steve was stating his opinion, but
I'm summarizing the result of meeting attended by Steve, me, and
others. Throughout "we" refers to the meeting consensus.)
* Lars Marius Garshol
|
| [...] if all of these changes are accepted for LTM 1.3 it will be no
| less expressive than XTM 1.0.
* Steve Pepper
|
| Not quite:
|
| * variant names with <resourceRef>
True. (We don't really want to support this in LTM 1.3, though.)
| * reification of association roles (at least acc. to proposal)
The proposal deliberately left this ambiguous. We concluded that as
long as TMDM supports this we want LTM 1.3 to support it. (And TMDM
does support it.)
| * untyped associations and occurrences
| * untyped association roles
We strongly feel that this should not have been in XTM 1.0 to begin
with, and we very much do not want this to be supported by LTM.
| Another goal, I think, should be to avoid multiple ways to express
| the same thing (even though this might otherwise have made the
| notation more compact).
I agree.
| We also need to consider the impact of XTM 1.1:
|
| * typed basenames
| * embedded XML
| * ... (?)
We felt that since the purpose of specifying LTM 1.3 now is to
describe what will be in the OKS LTM implementation (and, of course,
to help other implementations stay in sync) and since we do not
support XTM 1.1 in the OKS yet, we shouldn't support these features in
LTM 1.3. (Some future version of LTM should, of course.)
| 4. URI prefixes
| ...............
|
| Yes with comment:
|
| Suggest #PREFIX instead of #URIPREFIX. Rationale:
|
| * No point in making it more verbose than necessary
| * The term "prefix" is sufficiently clear
| * N3 has @prefix for exactly the same thing
We agreed to go with "#PREFIX".
| 5. Reification support
| ......................
|
| For some reason I find it very natural to use "@" as the delimiter
| for reification, even though (or perhaps BECAUSE) it is already used
| for subject indicators. (After all, reification involves regarding
| the syntactic construct as the subject identifier for the topic map
| construct that is being reified.)
We concluded that we did not want to use "@", for two main reasons:
- it's likely to lead to errors, where people type @foo when they
mean @"foo" (and vice versa) and do not get errors, and
- the "@" is too visually distinctive, and thus makes the reification
indicator seem like a separator, which it really is not.
| Would allowing
|
| "@" NAME
|
| after a name, association, role, or occurrence (or preceding any of
| the above, in the case of the topic map) be sufficiently clear and
| unambiguous, I wonder.
It would. Syntactic ambiguity is not the problem.
| Reifying the topic map would simply be as follows:
|
| @tm-topic /* preceding any topics, occurrences or associations */
We discussed this a bit, and felt that with the "@" character it might
cause confusion with the encoding directive, which is
@"utf-8"
Also, this syntax was felt to be a bit confusing to users, since it
might not be clear to them what was being reified. However, there was
general agreement that using
#TOPICMAP tm
[tm-topic = "The topic map" @"#tm"]
to reify topic maps, but
[tm-topic = "The topic map"~tm-name @"#tm"]
[tm-name : name = "The silly name of the topic map"]
to reify names (ie: different indicators, and having to use a subject
indicator explicitly to reify the topic map) was inconsistent, and
that more consistency would be nice.
In the end we settled on
#TOPICMAP ~tm-topic
[tm-topic = "The topic map"]
as the syntax, since this makes it obvious what is being reified,
avoids having to use subject indicators explicitly, while being nicely
backwards compatible.
| The only possibly confusing scenario would be when reifying a name
| and at the same time specifying a subject identifier for the topic
| to which the topic belongs:
|
| [ltm : syntax = "LTM" / acronym @ltm-name
| @"http://psi.ontopia.net/topicmaps/LTM"]
|
| However, the distinction between
|
| @ NAME
|
| and
|
| @ uri
|
| (where 'uri' is a quote-delimited string) is sufficient to prevent
| ambiguity, is it not?
It is.
| 6. Variant names
| ................
|
| I'm not sure I fully understand this proposal. Perhaps Lars Marius,
| could provide a description such as would go into the User's Guide
| to LTM. (If the proposal can't be described in simpler terms, then
| that in itself is a problem.) I'll comment on the proposal once I've
| seen the new description.
This was discussed at length, and in the end the meeting was
interrupted by another following it, with no conclusion being reached.
The following variants of syntax for variant names were suggested, but
no proper evaluation was done:
/* the original proposal */
[pepper : person = "pepper" ;;
; "koshoo" / japanese
; "EAAB" / korean
/ nick]
/* mischievous proposal by pepper, who as punishment has to be the
example topic */
[pepper : person = "pepper"
~ "koshoo" / japanese
~ "EAAB" / korean
/ nick]
/* grove's compromise proposal */
[pepper : person = "pepper"
- "koshoo" / japanese
- "EAAB" / korean
/ nick]
/* LMG tries to indicate the nesting and be minimal */
[pepper : person = "pepper"
("koshoo" / japanese
"EAAB" / korean ) / nick]
/* pepper's alternative */
[pepper : person = "pepper"
("koshoo" / japanese)
("EAAB" / korean )
/ nick]
/* pepper tries to outdo LMG in minimalism */
[pepper : person = "pepper"
"koshoo" / japanese
"EAAB" / korean
/ nick]
/* can't remember who suggested this */
[pepper : person = "pepper" / nick
"koshoo" / japanese
"EAAB" / korean]
/* shows why previous proposal is not backwards-compatible */
[pepper : person = "pepper" / nick ; "pepper"
"koshoo" / japanese
"EAAB" / korean]
Comments on all of this of course welcome.
--
Lars Marius Garshol, Ontopian <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50 <URL: http://www.garshol.priv.no >