[tmql-wg] TMQL Use Cases: Remaining Issues
Tue, 6 Apr 2004 18:26:15 +1000
I had a look at my left-over notes for the outstanding issues for the
TMQL use cases document. Some of these I have collected without
understanding their merit, so I am simply listing them here.
Some issues would involve that new use cases have to be added or -
more drastically - some of the data will have to be changed. As I do
not want to make such changes unilaterally I will post suggestions
here and only if there are no major objections, will add them to the
I will certainly not add anything before Amsterdam.
- Ad data:
> The subclass association does not use the right PSIs, so this
> means that query engines can't actually know that this is the
> magic superclass-subclass association type.
Currently, we have in the text:
"It is assumed that subclasses represents
http://www.topicmaps.org/xtm/1.0/core.xtm#superclass and subclass
This association type should have the implicit property that if a is
an instance of A and A is a subclass of B then a is also an instance
of B. The binary relation subclasses is to be interpreted
non-reflexive and transitive."
? Should we change the data to reflect this statement ?
- Ad data:
> uc-literature.xtm is not valid XTM, since <subjectIdentity>
> appears at the end; it has to go between <instanceOf> and
> <baseName>. (Found this in the new validating Omnigator.)
This is now fixed in the CVS version.
- Ad data:
> The sort names are not actually sort names:
> 1) they are not variant names, and
> 2) they do not use the correct PSIs (or any PSIs at all).
> It's still possible to sort on them, but they should be actual
> sort names.
I wonder, why they should, so what difference it makes.
In the prolog for the use case data we have currently:
"the basename value in the scope <code>sort</code> we call the
? Any good reason to change this?
- Ad query 220.127.116.11:
> The sample data does not have any subclass of tutorial with
> instances, so the "direct or indirect" part does not have any
> effect. I guess we should either take it out of the use case or
> add data to the topic map.
True. We have 18.104.22.168, though, which asks for this.
- Ad query 22.214.171.124:
> "publications" should here probably be "documents", since that's
> the topic type.
Not quite. Currently, the accompanying text says:
"Conversely, a publication is a document which has been authored
So there must be an authorship relation to make it a publication.
(Should actually be expressed in TMCL :-)
- Ad query 5.3.1:
> The results shown include non-papers TAO and colourful.
True. Fixed in CVS.
- New Use Case
Should we have a use case covering more complex associations with
several roles? All associations currently are binary.
If so, then the data has to be changed. Idea:
"Return all titles of documents which have been presented at the xml200x
- New Use Case
Do we want one for "types for basenames"?
- Use Case for reification of topics
Actually 126.96.36.199 should be read like this:
"Which topics reify something on that site"
I see that all solutions have interpreted it like this.
- Use Case for reification of associations
Change in the data:
(paper-is-presented-at) is-reified-by x123
in (entertainment-level): 5
"return all papers which were presented with an entertainment
level 5 (and above)"
- Use Case for reification of characteristics (yuck)
Change of data:
in (entertainment-level) is-reified-by x234 : 5
"return all presentations (paper and presenter) which
have been assessed by the XML200x conference audience"
- Use Case for source locators
- Use Case for Full Text Retrieval
Do we need more sophistication than what we have in 188.8.131.52?
Soundex, ranking :-)
- There references were missing. I have regenerated them and committed
a new version into the CVS. Maybe the Makefile does not work when being
executed by Lars?
- In the visible version at
most links do not work (documents not copied). Also the small image
at the beginning does not show up. It does in the CVS version.
- Do we need a "Conformance Test Suite"? It would formalize the use cases
and combine them with the expected outcome (CXTM?)
I think this should be done as soon as we have a bit more machine support.
Maintaining the use cases manually is VERY error prone.
- Shall we add here cases to outline that processors are allowed to
do 'lazy evaluation'? This is also something which might have to
be reflected in the TMQL requirements document.