ISO/IEC JTC 1/SC34 N0397, 2003-04-03
|
Title: |
SAM: Proposed Issue Resolutions |
|
Source: |
Lars Marius Garshol, Graham Moore, JTC1/SC34 |
|
Project: |
ISO 13250 |
|
Project editor: |
Steven R. Newcomb, Michel Biezunski, Martin Bryan |
|
Status: |
First committee draft |
|
Action: |
For review and comment |
|
Date: |
2003-04-03 |
|
Summary: |
|
|
Distribution: |
SC34 and Liaisons |
|
Refer to: |
|
|
Supercedes: |
|
|
Reply to: |
Dr. James David Mason |
This document sets forth the authors' proposed resolutions to all currently open issues in the Standard Application Model, together with the rationale for those resolutions. Interested parties are requested to offer their comments on these.
We propose that the constraint that a topic may only have a single [subject address] be lifted, so that the property [subject address] is replaced by [subject addresses], which is a set property.
The rationale is as follows:
· It is possible for two different locators to map to the same storage location, such that they will always return the same information resource at the same time.
· The OASIS XMLvoc TC found a practical need for the ability to have a topic represent an information resource stored in multiple places.
· It is possible for a topic to have subject identifiers that contradict one another, and this is not forbidden, since contradictions cannnot be detected. So long as subject addresses do not necessarily contradict one another it seems unnecessary to have this restriction.
See also the IRC discussion.
Since it was decided above to allow the [subject addresses] property to hold more than one value this constraint is now gone, and so this whole issue no longer applies.
We propose that SAM implementations should not be required to support any particular locator notation, since what interchange syntaxes an implementation supports will in any case determine what locator notations it must support.
As for what locator notations should be defined in the SAM we suggest that only those needed by an official interchange syntax should be added. More can be added as need arises.
See also the IRC discussion.
We are of the opinion that this issue is not important, and that it can be closed without further discussion.
See also the IRC discussion.
A general decision was made to not follow the implicit constraints in the XTM DTD (see xtm-implicit-constraints), and so we propose to allow this. The same applies to prop-subj-address-scope.
See also the IRC discussion.
We propose the name [value] be retained, on the grounds that the string is the value of the base name, but the label of the topic. As this is a property of the base name rather than the topic, [value] seems more logical than [label].
See also the IRC discussion.
Our position is that the model used by XTM improves on that of HyTM, and that the HyTM->SAM deserialization specification should be constructed in such a way as to handle this.
See also the IRC discussion.
The URI of the page that holds the SAM PSIs will also serve as the published subject identifier for all the PSIs defined by the SAM. There will also be URIs for identifying each version.
See also the IRC discussion.
We propose that superclass/subclass association loops should be allowed, with the following rationale:
· Detecting loops is going to be costly and complex for applications.
· There are legitimate use cases for such loops. (They allow one to express that a set of classes have the same extensions, yet different intentions.)
· The only reason to disallow them, as far as we can see, is that this allows certain optimizations when doing logical inferencing. Applications who wish to impose this constraint are free to do so, however.
See also the IRC discussion.
In our opinion the clarification of the scope rules make the semantics of applying scope to this relationshop clear, but even so we think the following example should be added to the specification in a note to make it clear to readers how to interpret this.
type-instace(a : instance, b : type) / Y X
super-sub(b : sub, c : super) / Y Z
See also the IRC discussion, which did not finish the first time, and so was continued later.
We propose that even if a topic reifies a topic map construct there should be no restrictions on what classes it may be an instance of, since:
· implementing such constraints are likely to be costly in practice, and
· it is not entirely clear what the semantics of this would be, nor what users are likely to want to do in practice.
However, we do propose that a set of published subjects for the topic map constructs that can be reified should be defined, so that those who wish to do so may use them.
See also the IRC discussion.
The editors think the original SAM conformance section is sufficient.
See also the IRC discussion.
We propose that the SAM should take the "scope is comprised of all subjects" view and state this clearly. The rationale is as follows:
· In the 'any' subjects view, the merging rules for topic characteristics will require topic characteristics equal except for in their scopes to be merged, thus violating the integrity of scopes.
· In the 'all' subjects view, the unconstrained scope is the empty set, which is more natural conceptually, and also easier for the query language to handle.
· Topic characteristic assignments that state that topic characteristic is valid in multiple different contexts is still possible, simply by repeating the characteristic assignments with different scopes.
· It also makes the consequences of scoping type-instance and supertype-subtype clearer. In general, it makes the use of scope easier, since the semantics of scope are defined.
· This decision greatly simplifies the handling of scope in the query and constraint languages for topic maps, since several kinds of scope matching operators are now no longer needed.
We note that to make it easier to repeat topic characteristics in different scopes we may want to make the scope element repeatable in XTM.
Since we have proposed to make scope 'all subjects' the unconstrained scope must necessarily be represented as the empty set. (See SC34 N0327 for the rationale.)
We consider that the model already contains the mechanisms necessary to achieve this, as using a data URL in the [subject addresses] property will effectively create a topic that represents the string the URL resolves to.
See also the IRC discussion.
We consider that this issue is out of scope for the SAM, but properly belongs in the Recommendations for Published Subjects to be published by the OASIS PubSubj TC.
We have added the following text to the last paragraph of section 3.4, which we believe makes the SAM equivalent with ISO 13250:2000 in this respect.
Applications and users are therefore free to merge topics as they see fit. Most commonly this will be done by inferring the subject of the topics from their characteristics.
We consider that to put a locator which refers to a subject that is not an information resource in the [subject addresses] property of a topic item is problematic. If we want to be able to infer that the subject of a topic is an information resource whenever the [subject addresses] property is non-empty this must be avoided. Clearly, it cannot be disallowed, however.
Therefore we propose to add a note stating that locators referring directly to subjects which are not information resources should be placed in the [subject identifiers] property. We can then also add text stating that a topic item whose [subject addresses] property is non-empty can be assumed to represent an information resource.
This issue was formally resolved at the Baltimore meeting, but has since been reopened in the light of later experience. We propose to resolve this issue by removing the restriction that the same locator may not appear in both the [source locators] and [subject identifiers] properties of a topic item.
The rationale is that this preserves the information originally in the source document, that it avoids confusing applications by removing locators they may depend on, and also that it does not cause any difficulties or ambiguities for implementation to have the same locator appear in both properties.
See also the IRC discussion.
We feel that while we have sympathy for this proposal it is too much of a change for this version of the standard and the XTM syntax. We also feel that this change on its own would in any case be insufficient if it were to be motivated on the grounds of symmetry between the three kinds of topic characteristics.