Topic Map Specifications | Customize | Filter | Export | Statistics | Vizigate

Description

Subject Identifiers (1)

Internal Occurrences (1)

Occurrences of this Type (115)

  • According to XTM 1.0 the default occurrence type is the "occurrence" published subject. Should this standard follow its lead? If so, what does it mean? (xtm-def-occurrence-type)
  • Are all information items in a data model instance required to be reachable from the topic map item by traversing the properties and items? (item-parent-required)
  • Are subtype loops allowed? (psi-subclassing-loops)
  • Are topic characteristic assignments statements about the topics's subject, or about the topic? (term-topic-characteristic-assignment)
  • Are topics representing information resources allowed as types? (prop-subj-address-class)
  • Are topics representing resources allowed as themes in scopes? (prop-subj-address-scope)
  • At what level of interpretation does the topic represent the resource? Does it represent that storage location? The stream of bytes? The stream of bytes interpreted in some particular way? The standard must either leave the details open or clarify this. Note that it may be impossible to clarify when the interpretation of locators is left undefined. (term-subject-address-def)
  • Attributes declared as #FIXED in the DTD can not be guaranteed to always be present in the XML document as parsed, either because there is no DOCTYPE declaration, or because the parser does not read the DTD. This affects both namespace and XLink parsing, which again affects the procedure used to recognize element types. (xtm-fixed-attributes)
  • Distinguish between properties which have containment semantics, and those which are references? (container-props)
  • Do the 'linktrav' and 'listtrav' attributes of the HyTM syntax have model significance? (association-traversal)
  • Do the definitions of the terms 'topic map processor' and 'topic map applications' have unwanted consequences for what software architectures can be conforming implementations of this standard? (term-tm-processor)
  • Do we need to define the term 'application' formally? (term-application)
  • Do we need to define what the empty set is? And the empty string? (term-empty-set)
  • Do we need to define what the empty string is? What about non-empty string (used liberally throughout)? (term-empty-string)
  • Does XTM allow full XPointer references, or only bare names? (xtm-href-xpointer)
  • Does the thing reified by a topic count as a characteristic of the topic? It is the subject of the topic, so the question is perhaps whether we are interested in the characteristics of topics or subjects. (term-topic-characteristic-reified)
  • Does this standard need to define how sorting of topics is done? It is a highly fundamental operation. On the other hand, users may want flexibility in this regard. (op-sorting)
  • For full internationalization it is necessary to support bidirectional text in names and occurrences. This requires that certain kinds of information be provided about the text. (string-bidi)
  • How are references from a topic map to elements which have no corresponding information item in the model interpreted? When they occur as occurrences, subject indicators, subject addresses or similar? (xtm-unused-ids-interpretation)
  • How does one determine which subjects are published subjects and which are not? Is it necessary for the SAM model to provide a mechanism for this at all? (psi-identification)
  • How does one uniquely identify the set of published subjects defined in SAM? Is there a need to do so? Is a published subject for these published subjects needed? (Does it include itself?) (psi-set-psi)
  • How should XML data be represented in the data model? (xml-data-representation)
  • How should the unconstrained scope be represented? (scope-unconstrained-rep)
  • How should values from infinite subject spaces be represented in topic maps? (infinite-subject-spaces)
  • ISO 13250 states that subject identity may be "inferred from the topic's characteristics." Does SAM need words to the same effect? (subject-identity-establish)
  • ISO 13250:2000 allows a display name to have a scope that is a subset of that of the corresponding base name. This apparent contradiction needs to be resolved. (prop-variant-scope-superset)
  • ISO 13250:2000 does not restrict display/sort names to a single base name, by design. Is it acceptable for SAM to do so? (variant-in-basename)
  • If a locator syntax allows equivalent locators to be given different syntactical expressions normalization must be applied in order to take this into account. Where should the text that sets out this requirement go? Does it belong in this document, or in the syntax specifications? (locator-normalization)
  • If it may not be null, why may it be empty? (prop-value-null)
  • If the subject identifier is a locator that does not refer to an information resource, what is the subject indicator then? This also applies to the subject address. (term-subject-indicator-def)
  • If the topic naming constraint is not retained by the standard, is there then any need for this published subject? Or will the base name then take over the function previously fulfilled by this published subject? (psi-display-name)
  • If you reify a topic name, does that affect your allowed type? If you reify an association, must you inherit its type? (reification-effects)
  • Is [label] a better name? (prop-value)
  • Is a base locator property on the topic map item needed by other specifications? (prop-base-locator)
  • Is it acceptable for the [reified] property to be computed, or must it be a fundamental property? (prop-reifier-computed)
  • Is it acceptable that constraint violations may be reported at any time? (err-constraint-violations)
  • Is it allowed for a topic to have the same locator item both as subject identifier and as subject address? If it does, must not this mean that the topic has two subjects? (merge-same-subj-ind-addr)
  • Is it an error for a topicRef element to refer to an element that is not a topic element? (xtm-topicref-notatopic)
  • Is it an error if a mergeMap element refers to an XML document that contains multiple topicMap elements without providing a disambiguating fragment reference? (xtm-mergemap-reference)
  • Is it likely that the term "IRI" will replace "URI" in the foreseeable future? Does there need to be well-defined mechanism for adding new possible values for the [notation] property? (prop-notation-interp)
  • Is the URI given in the xlink:href attribute (of topicRef elements) required to have a fragment identifier? (xtm-topicref-fragment)
  • Is the term "subject identity" needed? It is defined in XTM 1.0, but it is not clear that there is any use for it. The XTM 1.0 definition is: That which makes two subjects identical, or distinguishes one subject from another. (term-subject-identity)
  • Is the term 'theme' useful, or best forgotten? (term-theme)
  • Is this conformant to the XML c14n with respect to namespaces? (cxtm-namespace)
  • Is topic.[subject address] the right name for the property? We have [subject indicator], not [subject identifier], so why [subject address] rather than [subject resource]? (prop-subj-address-name)
  • Is whitespace allowed in the xlink:href attribute? If it is allowed, how is it interpreted? If it is not allowed, what action is taken when it is found? (xtm-href-whitespace)
  • Must both [role playing topic] and [role type] have values? (assoc-role-player-type)
  • Must locators really refer to information resources? Some URN schemes allow resources that are not information resources to be addressed. This affects the definitions of "information resource", "locator", as well as the [subject identifiers] and [subject addresses] properties. (locator-reference)
  • None of the interchange syntaxes allow source locators to be interchanged. Is interchange of source locators a desired feature? Do the syntaxes need to be extended to accomodate source locators? (prop-srcloc-interchange)
  • RFC 2396, section 4.2, specifies that URI references of the form "" and "#fragment" are resolved relative to the URI of the current entity. Should XTM should follow this? (xtm-same-doc-refs)
  • Should HyTM mnemonics be represented in the model using special properties, or should they be represented using already existing constructs? (mnemonic-representation)
  • Should all or some element types which have xlink:href attributes also be given an xlink:actuate attribute? If so, what should the legal range of values be? (xtm-xlink-actuate)
  • Should all types be called classes, all classes types, or should both terms be used? Which terms should be used where? (type-vs-class)
  • Should base name items be merged, so that assertions made about one base name will also apply to all other base names that have the same identity? (This also applies to occurrences.) (names-as-subjects)
  • Should base names be allowed to have both types and scopes in the same way that occurrences do? (names-with-types)
  • Should it be possible to create topics that represent strings, and for it to be formally clear that these topics do represent particular strings? If so, how? (strings-as-subjects)
  • Should it become possible for the scopes of topic characteristic assignments to have internal structure? (prop-scope-structure)
  • Should multiple resourceRef elements be allowed inside subjectIdentity? (xtm-subjectidentity-children)
  • Should occurrences be allowed to have variants in the same way that topic names are? (occurrence-variants)
  • Should resourceRef be allowed in roleSpec, instanceOf and parameters? (xtm-where-resourceref)
  • Should source locators of B be copied into A? If they are, it is implied that A is the same topic map as B, which is not true. Also, topics reifying B will then also reify A, which means that any statements made about B will also apply to A. (merge-prop-srclocs)
  • Should the "topic", "association", and "occurrence" PSIs be specified in the SAM? If so, what do they mean, and what is their function? (psi-generics)
  • Should the DM have a conformance section of its own? If so, what does it mean to conform to the DM? (sam-conformance)
  • Should the UML diagrams be made normative? (meta-uml-normative)
  • Should the XSDL and RELAX-NG schemas declare xlink:href attributes to be of type URI? (xtm-schema-uri)
  • Should the [subject addresses] property be called [subject locators] instead? (prop-subject-addresses)
  • Should the [value] property be normalized? Note: This issue also applies to occurrence items. (cxtm-resource-data-normalization)
  • Should the id attribute of member be ignored? This makes it impossible to reify association roles in XTM. On the other hand, member elements do not necessarily map to a single association role item. (xtm-member-id)
  • Should the parameters element type be deprecated and replaced by scope? (xtm-parameters-deprecate)
  • Should the specification have a non-normative section providing guidance for implementors on how to do reserialization properly? (xtm-reserialization-recommendation)
  • Should the standard retain the topic naming constraint? (topic-naming-constraint)
  • Should the standard say as little as possible about the nature of subjects, or should it be more detailed in order to provide guidance to readers? The current text is detailed, but may be too much so. (term-subject-def)
  • Should the standard state outright that "subject" and "resource" (as per RFC 2396) are the same thing? (Quote: A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., "today's weather report for Los Angeles"), and a collection of other resources. Not all resources are network "retrievable"; e.g., human beings, corporations, and bound books in a library can also be considered resources.) (subject-vs-resource)
  • Should the subject identifiers defined by XTM 1.0 be retained as they are, or should new equivalent ones be defined to replace the originals? (psi-topicmaps.org)
  • Should the topicMap element have a version attribute? (xtm-topicmap-version)
  • Should the variantName element type be deprecated, and the content model of variant be adjusted to make it redundant? (xtm-variantname-deprecate)
  • Should the version number in the XTM namespace URI be changed? (xtm-namespace-uri)
  • Should the xml:base attribute be allowed on every non-empty element type? (xtm-xmlbase-everywhere)
  • Should there be a computed [parent] property on all information item types except the topic map item type? (prop-parent)
  • Should this property only accept a single value? (prop-subj-address-values)
  • Should topic items be required to have a value for at least one of the [source locators], [subject indicators], or [subject locator] properties? (topic-identity-required)
  • Should topic items have a [reifier] property? Should it be possible to reify topics? If so, how? (prop-reifier-topic)
  • Should topic map items have a [schema] property that may contain their schema definition(s)? This would make it clear where to find the topic map schema. On the other hand, the TMCL specification should perhaps have its own rules for specifying how to find the schema of a topic map. It may be better to keep the levels strictly apart. (prop-schema)
  • Should we always output an ID attribute, or only when the topic map is reified? (cxtm-topicmap-id)
  • Should we define an equality criterion for topic map items? There is no need for duplicate removal for topic maps, but on the other hand that would be what is needed to define the conformance requirements on serialization implementations. (op-topic-map-compare)
  • Should we define operations that describe how modification of SAM instances is done? (op-modifications)
  • Should we extend the content model of resourceData to allow arbitrary markup within the element, and require implementations to be able to represent this? (xtm-resourcedata-markup)
  • Should we have the topic.[classes] property? It means either that classness cannot be scoped, or that classness has a double representation. The question is: is scoping of classness important? Does it cause problems for implementations and applications? (prop-classes)
  • Should we name the type properties [association type], [role type], and [occurrence type], or should they all be called [type]? (prop-type-properties)
  • Should we retain the id attribute on element types which do not represent something that can be reified? (xtm-unused-ids)
  • Should we speak about 'equality' of items, or 'equivalence'? (term-equal)
  • The XTM DTD contains a number of implicit constraints, such as that an addressable subject may not be used as a theme or a type. Should these constraints be mirrored in the SAM? (xtm-implicit-constraints)
  • The definitions of 'base name' and basename.[value] are too na├»ve in the presence of the TNC. If we are to have the TNC they must change. (term-base-name-def)
  • The presence of a TMCL schema may allow applications to improve the result of merging topics/topic maps by providing enough information to allow implementations to do additional transformations and redundancy removal. How should the SAM specification deal with this possibility? (merge-use-of-schemas)
  • The purpose of this topic map is to document the topic map standards process, and thereby make it easier to follow and easier to understand its result and the rationale for that result. The topic map is entirely unofficial. (Topic Map Specifications)
  • The rules for ordering association role items in section are not sufficient to make comparisons of [role played] properties in all cases. (cxtm-topic-roles-played-order)
  • The scope of ISO 13250 is currently restricted to only defining the issues related to the interchange of topic maps. Should that scope be extended so that the standard can also cover application-internal issues? (scope-extension)
  • The term "subject address" does not correlate with the term "subject indicator", since "subject address" corresponds more clearly to "subject identifier". A better name should be found. (term-subject-address)
  • The text as specified here requires that XTM processors do XML Namespace processing. Is that acceptable? XTM 1.0 seems to imply that namespace processing is optional. Also, proper namespace processing allows the use of different namespace prefixes, which break straight DTD validation. (xtm-namespace-support)
  • The text as written implies that processors must use a Unicode normalization form, without requiring any particular one. The Web Character Model requires Normalization Form C, as does the current XML 1.1 Working Draft. Requiring normalization improves string comparison, but imposes a possibly unwelcome burden on implementors. (string-normalization)
  • This definition of scope is different from that of XTM 1.0 and ISO 13250:2000, in that it explicitly says topic characteristic assignments are valid for each of the subjects in its scope individually. Is that acceptable? (term-scope-def)
  • Unknown elements are ignored in order to ensure forwards compatibility, but this means DTD compliance cannot be required. Which is more important? (xtm-unknown-elements)
  • What does it mean when type-instance associations are scoped? How is this to be interpreted, and what is the interaction with scoped supertype-subtype associations? (psi-type-instance-scope)
  • What happens if a resource that is not an XTM document is referenced with mergeMap or topicRef? (xtm-reference-non-xtm)
  • What happens if two different topic items reify the same item? Should they be merged? (reifier-merging)
  • What happens when external references from an XTM document fails? Note that only topicRef and mergeMap references can fail, since these are the only references followed by an XTM processor. (xtm-external-ref-failure)
  • What happens when the same locator appears as a source locator for one topic and as a subject identifier for another? Does that locator then become a source locator or a subject identifier of the merged topic? This question arises both under deserialization and under merging. (merge-srcloc-vs-subjid)
  • What happens when the single subject address constraint is violated? (constr-single-subject-address)
  • What if the topicRef element refers to a topic in an external resource where the topicMap element is not the document element. Is that an error? What if there is more than one topicMap element? (xtm-topicref-xtmwrap)
  • What is the correct behaviour if a topicRef to an external document occurs first, followed by a mergeMap with added themes? (xtm-mergemap-and-topicref)
  • What locator notations, if any, must be supported? (locator-notation-support)
  • What version number should we give the updated XTM syntax? (xtm-version)
  • Where should the indicators for the subjects published in the new ISO 13250 be published? (psi-publishing)
  • Which schema should be the normative schema? (xtm-normative-schema)
  • XTM 1.0 has a term "topic name", but it is not clear how it relates to the term "base name". Its use in XTM 1.0 seems to be inconsistent. Is the term useful, or should it be abandoned? (term-topic-name)
 
Object id: 10
Item identifier(s):
[file:/home/webadmin/ontopia.net/oks-online-demo/apache-tomcat/webapps/omnigator/WEB-INF/topicmaps/tm-standards.xtm#description]