|
Title: |
Japan National Body Comments on SC 34 N 327, 328, 329 and 331 |
|
Source: |
SC34 National Body of Japan |
|
Project: |
|
|
Project editor: |
|
|
Status: |
|
|
Action: |
For Information and Review |
|
Date: |
2002-10-08 |
|
Summary: |
|
|
Distribution: |
SC34 and Liaisons |
|
Refer to: |
|
|
Supersedes: |
|
|
Reply to: |
Dr. James David Mason |
On the issues resolved in Montreal we agree with most; however, we are against the resolution on the topic-naming-constraint (TNC) issue.
The question, "Should the standard retain the topic naming constraint?" was raised.
We agree that the topic naming constraint (TNC) rule should be maintained. However, we do not think that it should be required. In XTM 1.0, since the base name can either be used as a label or as an identifier, we can never really be sure which one is intended by the topic map author. This non-specificity is not acceptable. We agree that it is a reasonable requirement to allow the use of a base name within a particular scope and not use the name for name-based merging.
There is a problem now with making TNC rule required, especially when applied to all topics in the unconstrained scope. To avoid TNC merges, some topic map authors are forced to "protect" their names by scoping the topic by itself. The application of this kind of workaround reveals the problem. Therefore, requiring name-based merging should be disallowed.
The solution put forth at the meeting, the adding of a merge attribute to the baseNameString element and giving it the values of on and off with on being the default (for backwards compatibility), is not an acceptable solution.
The concern is related to issues that were raised by Marc de Graauw on Sept. 4, 2002 in http://isotopicmaps.org/pipermail/sc34wg3/2002-September/000512.html, that is, the same BaseNameString could appear twice and be assigned to have either the TNC applied to it or not. This creates vagueness as to meaning of the name itself and it would be hard to decide what this difference actually means. The same base name with attributes on and then off could actually be representing the same subject, but the markup would be indicating that they are two different subjects. Also, what happens when the same name has one attribute specified as on, the other as off, and they both have the same subject identity as defined by SubjectIndicatorRef?
The Japan National Body requests to revisit this issue and consider to either
1. apply some indication that the topic naming constraint rule will apply within some scopes but not others (this would need to be looked at with the issues related to scope),
2. allow label to be used instead of base name string, (to indicate not to use this name for name-based merging), or
3. consider other proposals such as the one we submit below.
The BaseName includes the BaseNameString and also VariantNames. This is the "base," the most fundamental concept of name. It would be reasonable not to have the topic naming constraint apply to the BaseName in principle (since it does not apply to variant names already which are also part of the BaseName) and hence, not to have the TCN apply to strings in "BaseNameString." We propose that instead of defining a "label" for a name that would not have the TNC rule applied to it, we should define an element for a name that would have the TNC applied to it, something like TncNameString. We realize that this would break backwards compatibility, but the topic map authors now applying the TNC to BaseNameString could easily make the change in element name. It makes more sense, in our view, to make this TncNameString, the special case, since identity is already defined through SubjectIndicatorRef.
In summary, before any proposal on whether the topic naming constraint rule should be applied to the base name or not or how it should be applied, we need to decide what the base name is, what parts make it up, and which parts would signal when the TNC is applied. We prefer to define some additional element for this purpose, instead of an attribute, but this is not the main issue. The definition is, and once this is cleared up we can begin to work on the syntax.
In keeping with the syntax modifications as described above, we request to keep this issue open and revisit alternatives.
The meaning of the resolution, have two different string properties on the base name item; one for labels and one for identifiers is too general to understand the context. In principle, it seems to go along with our proposal, but the definition of base name itself needs to be clarified.
The discussion paper SC 34 N 327 is currently being reviewed, and we thank Marc de Graauw for his contribution. From the ideas presented, it seems that a more structured scope would create a more richly descriptive model. We request that the proposals from Kal Amed, Steve Pepper and Geir Ove Grønmo, and Bernard Vatant be formally submitted for review and comment
It seems necessary for scope to be specified explicitly as described in Kal Amed's proposal. Whether a specific method should be described in the standard, needs to be discussed. This kind of discussion may be useful later on and could be included in an informative annex.
We agree to replace the terms intersection/union with any subjects/all subjects. Therefore, scope as intersection would be replaced with "scope in the any subjects view" and scope as union would be replaced with "scope in the all subjects view."
It seems from the discussion in Montreal that some implementers would like to continue to define scope in the any subjects view when the TNC is applied, and others would not. As Marc de Graauw points out, in the “any subjects” view the merging rule cannot be correct (unconstrained scope is the set of all subjects in the Topic Map without an explicit scope). It the “any subjects” view is kept, the TNC rule would need revising. The benefits that we would gain by changing to the "all subjects view" needs to be discussed further and more examples are needed for clarification.
We agree with the comment in the report that "Scope as it is currently defined is too weak." We propose that Steve Pepper and Geir Ove Grønmo, based on their paper "Towards a General Theory of Scope," formally submit an extended definition.
The formal data model XML Infoset should be stated explicitly here. "Defining the semantics of topic map constructs using prose" does not seen necessary to say here.
Note: From the very beginning, the methods of expressing terminology need defining. Information items are defined with brackets. This is explained in the XML Infoset model, but it would be worthwhile to explain the usage of brackets in the SAM. Also, information items from the XML Infoset such as [children] need some indication that they are in fact definitions from the XML Infoset model and not from the SAM. We suggest adding a reference superscript to these.
This section needs an exact description of the metamodel and an explanation of information items and properties as they relate to the SAM. With regards to the XML Infoset, it is important to distinguish the parts of the XML Infoset model that apply to the SAM versus those that do not. For example, the notion of "namespace" in the XML Infoset versus the Topic Maps specifications requires clarification. The term "namespace" needs to be defined rigorously in the SAM.
Need some background on these before they are discussed.
The second sentence in the first paragraph needs clarification. "... source locators are created that point back to the syntactical constructs that gave rise to the information items in the information set." The next sentence clarifies it a bit, but a more explicit example is needed for this abstract concept.
We have definitions for "subject indicator" and "subject identifier" which are paired. We also have subject address. It seems to be missing its "mate." This is the subject-constituting resource? We may need to add this term or coin a new one.
The prose in this section is not complete and must be reworked.
The description in this section differs with previous descriptions of topic characteristics as defined and understood in the XTM 1.0 Specification defined by topicmaps.org. The prose must be reworded to reflect the change in thinking, since it is central to the topic map paradigm.
It is important to place emphasis on the statement "Any topic characteristic assignment constitutes a statement about the subject represented by the topic as opposed to and contrast it with those that do not, but instead, are only making statements about the topic itself. This is quite difficult to understand in its abstraction. Examples in this case would aid in making it clearer to the readers. This section needs to be related to section 3.4.5 Properties, to aid in understanding.
This section requires further explanation as to the nature of topic items representing topics, which in turn represent subjects.
If the scope is composed of a set of subjects, then the "any subjects view" would not agree with this definition of scope as stated in out comment to the issue (term-scope-def) in the Montreal minutes.
In Montreal, it was agreed to drop the term "theme." The concept has not been dropped so "topics used in scopes" needs some explanation.
The sentence, "Precisely how a subject defines a context is not constrained by this standard, but left for those creating topics representing subjects used in scopes to define as part of the definition of their subject." It does not add to the meaning of a very difficult concept and is better left out.
Scope is applied to topic characteristic assignments of base name, occurrences and association types. Bringing up "creating topics representing subjects" confuses this concept. What is scope applied to? This sentence is explaining how scope adds to the definition of the subject in how it constrains its context? The subject is defined, based on the scope applied to it? Those creating topics representing subjects (the topic characteristic assignments?) will use scope to refine the meaning of their subjects? What is the difference between this and typed occurrences?
The sentence, "Reification is thus a special form of representation," needs some explanation. What is this special form?
In the next paragraph, What is "association occurrences?"
This part may need to be in a section in its own right. Does this mean to use a topic to reify a topic map construct, or does it mean attaching information to topic map contructs?
This sentence needs clarification. You are discussing how to attach occurrences to associations? What does it means to "associate a base name with certain topics?"
The sentence is especially unclear, "if any information item has in its [source locators] property a locator item equal to one in the [subject identifiers] property of this topic item, that information item is the value of this property."
The information item is reified by its topic item? It them becomes the topic map construct that this the subject of the topic? It is difficult to ascertain what "this" is being referred to. Change "this property" to "reified property" in all instances to make it clearer.
Identity "this property" as "reifier property." Add a comma between ... of this information item, (then) that ... Need to add "then?" Review all uses of "this" and "that" in the sentence and use concrete expressions to define abstract concepts.
In discussions with the author, it was suggested to change the term to "reifing topic." This seems better.
It is written, "The allowed syntactical expressions in XTM documents are constrained using a DTD and prose." Remove "allowed" since this is explicit if "constrained." The syntactical expressions are "constrained" by the DTD but "defined" by prose. Constrained by the DTD seems to be enough. We suggest to also remove "and prose."
Note: As described above for the SAM, the use of brackets for properties in the SAM and in the XTM syntax specification needs defining and a way to express where the originals definitions reside. Need a reference to bracketed items that are defined in the SAM.
In the third paragraph [children] property needs a reference since this is defined in XML Infoset. Missing commas to help in the understanding. Need commas after "If the occurrence element has a resourceData child element," and after "and for each information item."
Where is the [character code] property defined, in XML Infoset, in some Unicode standard? These bracketed properties need a reference or need to be defined in a glossary within the document
The meaning of "traverse" is unclear. In a communication with the editor, he explains it as meaning to go through the information items in the [children] property one by one in document order. Please add that to the document to clarify the meaning.
Missing commas in the forth paragraph after "child element, an absolute..." in the first sentence and in the next sentence, "From this URI, ..."
Need to define the source of bracketed terms for properties of information items.