Topic Map Specifications | Filter | Export | Statistics | Query

Opinion

Subject Identifiers (1)

Occurrences of this Type (88)

  • 1.1 ? But if so, then there we need a backward compatibility chapter (and maybe an XSLT sheet). (xtm-version)
  • 1.1. AFAIK, we are only adding instanceOf on baseName (and possibly allowing resourceRef in three more places). Even if we add variants to occurrences, I still don't think that justifies going to 2.0. From the point of view of conveying stability, we want these changes to be seen to be minor tweaks. (xtm-version)
  • Apart from all the subject/topic stuff there is another argument to drop the 'topic', 'association' and 'occurrence' PSI's. They are most uninformative. Since any topic is an instance of class 'topic' by default (unless specified otherwise, says XTM), there is no information involved that is of any use to anybody. The user of the Topic Map will not want to see the class 'topic' listed among the classes of a topic; therefore a Topic Map engine will have to suppress it, and it makes no sense to me to introduce a property which only needs to be suppressed later. For the Topic Map engine there is also no useful information in the PSI, since Topic Map engines 'know' what topics are (i.e. how to process them) without using this PSI. So to me it seems a piece of redundant information. Same goes for the 'association' and 'occurrence' PSI's. (psi-generics)
  • Bare names. (xtm-href-xpointer)
  • Given the possible multiple types of schema/DTD for Topic Maps based on ISO 13250 architectural forms, SAM should record the source of this information. (prop-schema)
  • I agree that this is not a strong form of "conformance" and that TM?L will be a much stronger vehicle to do that. (sam-conformance)
  • I believe unwarranted merging would occur when using the TNC if it weren't "All-themes," and that therefore scope should be defined as made up of all themes. (term-scope-def)
  • I dont see an issue here. We have the notation property and we say the default is URI. fine. There is nothing to stop new notations coming along. At the moment we dont have any form or enumeration of notation types and i dont think we should. (prop-notation-interp)
  • I dont think it matters. I think we state that is it retrieved based on matching subjinds and srclocs and implementors can choose if they do a computed look up or its just there. (prop-reifier-computed)
  • I dont think we define it. If for no other reason than we dont have to define what equality is other than the locator. If i had to take the other extreme position i would take the one similar to library science that distinguish between the concept of a work and the individual work. In tm I would adopt a position that this is a stream of bytes from a location. i.e. it is the individual work. (term-subject-address-def)
  • I like URIs a lot. Yes. (xtm-schema-uri)
  • I tend to think a PSI for "topic" is of no use at all (psi-generics)
  • I think TM needs the concept of a literal. If a topic is a string it has to be the concept of a particular string and not an individual instance. If people represent the concept '1' or 'gra' as a topic thats up to them. But for it to be useful i think they need to be able to have a topic or probably a literal that is a particular instance of the concept. (strings-as-subjects)
  • I think it is more likely that it is the [subject indicator] property which is incorrectly named. The thing you get from this property is the address of the resource, not the resource itself and the name should reflect that. (prop-subj-address-name)
  • I think it would help to state that 'an application is some computer process that provides functionality where that functionality utilises a tm processor and the topicmap(s) it manages.' An application itself does not manage the storage or structural integrity of topicmaps. This is done by the TM Processor.' (term-application)
  • I think that makes sense. (xtm-schema-uri)
  • I think that the SAM should be concerned only with the information model for topic maps. Any adjuncts to handle topic map schema should be built on top of the SAM. Presumably it should then also be a goal for TMCL and other extension specifications to ensure that any additional information items are available as computed properties from basic SAM properties. (prop-schema)
  • I think this is out of scope for us. I think we should say that if tm processors wish to apply schemes for deciding syntactic equivalence then they can do. But i dont think we can force this on people. (locator-normalization)
  • I would prefer if TM processing does NOT do too much link magic. If we keep it orthogonal then the standard has some freedom later. (xtm-href-xpointer)
  • I would tend to the any-subject view for backward compatibility if there is a reasonable way around the problems with the set of all topics (or similar contructs). (term-scope-def)
  • ISO 13250 deliberately allows subject identity to be "inferred from the topic's characteristics." SAM does not seem to allow for this. (subject-identity-establish)
  • ISO 13250 does not recognize the "occurrence" default type introduced for XTM. If this is imposed on the standard, then a means of clearly distinguishing default types from user-defined types needs to be added to the model so that imposed subjects specific to the management of the model can be distinguished from the subjects that the author specified as part of the Topic Map. (xtm-def-occurrence-type)
  • ISO 13250 specifically states that the subject identify "may or may not be machine-interpretable, or may or may not be online". As noted above, it can also be "inferred from the topic?s characteristics." Therefore SAM should not confuse subject and resource as they are clearly two different things. (subject-vs-resource)
  • If there's no place to put them in the SAM, they have to be removed. Any elements for which the corresponding information item doesn't have a source locator will have their IDs ignored. (xtm-unused-ids)
  • It should be possible to create topics that represent strings. I might want to create a topic that refers to all occurrences of the string XML (strings-as-subjects)
  • It should become the source locator. (merge-srcloc-vs-subjid)
  • It's useful. (term-theme)
  • Locating the schema information should be kept separate from the SAM, and TMCL should be responsible for linking constraints to the topic map. (prop-schema)
  • My feeling is that the SAM should only concern itself with those rules for scope that are required to make the SAM internally consistent and to allow the application of rules such as name-based merging and duplicate identification. As far as I can see, there is a need to express a rule for equivalence of scope sets and that is it. (term-scope-def)
  • No magic here please. This is NOT about hyperlinks, btw. (xtm-xlink-actuate)
  • No, raise error. This is XML, anyway, so strictness is ok. (xtm-href-whitespace)
  • No. xml:base is an ugly cludge which is mostly used to hide design flaws. If someone needs it he can create submaps. I could live with it on the toplevel, but that's about it. :-) (xtm-xmlbase-everywhere)
  • Normalization Form C should be adopted in conformance with W3C rules for XML. (string-normalization)
  • Occurrences with no type should have an undefined relationship instead. What practical purpose does this default type serve? (xtm-def-occurrence-type)
  • Re "Does it represent that storage location" the answer must be no. What if the address is reassigned to different hardware containing a copy of the referenced resource? What if the address is notational, as in the above example? What if there are multiple copies of a particular resource (whether notational or not, as per retrieval from caches rather than the original resource)? This must be left an open issue for applications to determine. (term-subject-address-def)
  • Referring to RFC 2396 is likely to only be relevant for a short while. Already IETF have published a draft on Internationalized Resource Identifiers (IRI) that may well replace this specification in the longer term. The requirement that all other values must begin with ?x-? is unsupportable given that IRI might be needed in place of URI by the time SAM is published by ISO. (prop-notation-interp)
  • Say little that is normative, and you can say a lot that is non-normative. I would not want my subjects to be constrained in any normative way. (term-subject-def)
  • Since the definition is broken anyway, and there is no clear need for it, I suggest it be dropped. (term-subject-identity)
  • So, I really do think that conformance to the SAM (or TMM) makes not much sense at all, it is entirely a matter of API/Query languge conformance. (sam-conformance)
  • Spaces within a URL are disallowed, so strings are simply not URLs of they contain them. All spaces should be escaped (a '%20'). (xtm-href-whitespace)
  • The DTD. (xtm-normative-schema)
  • The XTM syntax needs to be extended so that source locators can be represented in full. (prop-srcloc-interchange)
  • The concept of theme was deliberately introduced into ISO 13250 to avoid the ambiguity that occurred when the word topics was used to describe the set of referenced topic map concepts used to scope an item. Dropping this term is likely to lead to ambiguities within SAM. (term-theme)
  • The part about the subject...is it necessary here? Looks more as an abstract introduction into TMs. (term-subject-def)
  • The requirement that variant names be associated with specific base names is incorrect. A topic with more than one base name would have to repeat the variants associated with that base name for each base name. (This was a deliberate design feature of ISO 13250 as it was realised that the same symbol could be used for a topic which had been assigned multiple base names, either as synonyms or as language-specific versions.) (variant-in-basename)
  • The way in which a subject address relates to a subject is in many ways related to the means of dereferencing the address. For example, a single http: protocol URI can be dereferenced to many different byte sequences - so the subject address cannot be considered to represent the content at that location. Equally, a urn:isbn: reference cannot be dereferenced at all and could be considered meaningless as a subject address, whereas a unique object identifier in a content management system may actually always return precisely the same sequence of bytes and so could be considered to represent a specific binary object. It might be useful for the SAM to say something about the stability requirements of a subject address - e.g. to represent a specific binary object, a subject address must be given in a notation which cannot be interpreted in such a way as to retrieve two different byte-sequences (excepting error conditions such as network or server outages). (term-subject-address-def)
  • There is too much text about subjects and their nature. is this really relevant in the sam spec? (term-subject-def)
  • This issue is determined by term-scope-def. If scope is "all subjects" then the unconstrained scope must be the empty set, while if it is "any subjects" it must be the universal set. If we choose to leave scope undefined this issue will require some thinking. (scope-unconstrained-rep)
  • This may constrain subjects, so I would be hesitant to do this. (subject-vs-resource)
  • This property should not be a fundamental property. (prop-reifier-computed)
  • To fully represent ISO 13250 Topic Maps SAM must allow for locators that do not address information resources. (locator-reference)
  • Unless/until there is a common API, I think SAM conformance in terms of an API are pretty meaningless. What is not meaningless though are the operations that the SAM requires a topic map processor to perform and validation that a processor does indeed perform those operations is probably best done not by inspection but by testing the application against a conformance test suite. So SAM + CXTM + conformance test suite is needed to prove the level of conformance which I as a user would expect from an application, and to which I as a developer would build my topic map processing software. (sam-conformance)
  • Yes, they should be merged. (reifier-merging)
  • again this is an error. the question is do we have any operations or other semantics defined within the SAM that will be confused or operate erroneously if we dont define this an error. (merge-same-subj-ind-addr)
  • erm - yes i think so. What situation were you considering where this wouldn't be needed. If a topic always has to be in an topicMap parent element. (xtm-topicref-fragment)
  • how do names have identity? Through being reified by a topic? Through having the same literal value? This is bad jazz and i think we want to avoid it. (names-as-subjects)
  • i thought that maybe 'nameString' was better. (prop-value)
  • in an ideal world i think yes it should. This are the kinds of details that make the standard robust but also increase the bar in terms of implementation participation. However, i think there is one major factor that prevents us from defining this constraint and that is that we dont define the semantics of type. We simply have it as a property of a topic. But unlike conventional knowledge modelling standards we don't define the concept of class-subclass nor the notion of transitivity - both of which are truly fundamental to being able to answer the queryion 'what type is this topic'. given we dont define it people are free to say in their applications that certain types extend or inherit from other types. Thus how are they or more importantly another tm processor to know how to answer the question 'Is this reified name of a valid type?'. Lets not constrain these aspects yet. The development overhead is high and the semantics unclear. (reification-effects)
  • lets say so. but perhaps define or say why the tm definition is more refined. i.e. we can distinguish whether the resource is network retreivable etc. (subject-vs-resource)
  • lose it. (term-theme)
  • no the thing reified by a topic is not a characteristic. (term-topic-characteristic-reified)
  • no. a topic that just is, just is. We have already stated earlier that topics have identity within the tm processor independent of any properties. Even subjinds. (subject-identity-establish)
  • no. nulls should be allowed. but maybe not nulls in both places? i.e. you have to have either role player or role type. i.e. you either dont know what is playing the role or you know this thing is associated but not yet why. (assoc-role-player-type)
  • not at all. this is well out of scope. (merge-use-of-schemas)
  • not our problem. (infinite-subject-spaces)
  • not really for sam to do. I would expect the OASIS group on PSI technology, whatever, to have some meta semantic to resolve the psi server etc. not out job. (psi-identification)
  • not sure. it can be added without breaking any existing stuff which is good. But do we really need it? What does it mean to interchange srclocs? (prop-srcloc-interchange)
  • ours is not to reason why. perhaps someone wants to do some merging, turns on tnc and gives the topics they want to merge a basename of "". Other than that its silly and should probably not be allowed. (prop-value-null)
  • personally i hate basename. we should really drop basename and use topicnam - but i guess the syntax legacy stops us from doing so. (term-topic-name)
  • probably dtd compliance. software etc and perceived reliability of tm is preserved as people will at least only be importing valid xml instances of xtm. The engines can throw back invalid xml errors rather than topic map exception. (xtm-unknown-elements)
  • probably not - but i dont think we should enforce it. Can we have an optional exception or warning? This feels more like a warning. Kind of like in Java when you cast a long to an int and you get a precision warning. (prop-subj-address-class)
  • probably not but we shouldnt enforce it. again maybe a warning if the processor deems it useful. (prop-subj-address-scope)
  • probably...? What if you just have a stream of xtm from an unknown source? Is the base uri used here, what if thats also missing. (xtm-same-doc-refs)
  • subject indentity is the collective term for the formal identifiers of a topic namely a resoure reference or subject indicators. Therefor i think it has a use beyond the xtm 1.0 spec definition. (term-subject-identity)
  • the name [label] would be a distinct improvement. (prop-value)
  • the subject. The topic is the proxy for the subject in the system thus they are about the subject. A property such as 'when was this proxy created' is a property of the topic not the subject. (term-topic-characteristic-assignment)
  • tnc is gone basically so i feel these defs are ok - if not yet perfect. (term-base-name-def)
  • we could leave this one to be addressed by the conformance activity? (op-topic-map-compare)
  • we should define it for completeness. As [with strings]: 0 elements and not null. (term-empty-set)
  • we should evaluate them and not be afraid to NOT model them in the same. i.e. constraints such as 'A Topic that *is* a resource cannot be a used as a scoping topic.'. I'm actually torn on this one. It seems like we'd be adding some sensible 'real-world' usage constraints. But this also prohibits people from doing cool funky things we havent thought of yet. (xtm-implicit-constraints)
  • yes (prop-subj-address-values)
  • yes i think it is. (xtm-mergemap-reference)
  • yes its allowed. if it doesnt validly ref something then tough luck. (xtm-href-whitespace)
  • yes they should and we should declare tm errors if a topic reifies contradictort things. i.e. a name and an assoc cannot be merged. (reifier-merging)
  • yes they should for completeness but it MUST return the topic. Topics are like the hall of mirrors they are reificantions of themselves and some subject. We need to end the cycle, to complete it, from the platonic form to the abstracton. This little pattern gives closure. (prop-reifier-topic)
  • yes we should define it. First stage would be to say that the empty string is a Unicode strin of length 0, explicitly it is not NULL. (term-empty-string)
  • yes we should distinguish. We have already stated that we define structural constraints and operations. Thus something like remove perhaps should be discussed. Perhaps only informatively - but the structural constraint that there can be no floating names once a topic has been deleted should hold normatively. (container-props)
  • | Should say almost nothing about subjects other than they are represented in a topic map by topics. This is the topic map standard and not the "true world view epistemology standard." (term-subject-def)
 
Object id: 28
Item identifier(s):
[file:/apps/ontopia.net/tomcat/ontopia-5.3.0/topicmaps/tm-standards.xtm#opinion]