Graham Moore

Scoped Occurrences (43)

• 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)
• 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)
• not at all. this is well out of scope. (merge-use-of-schemas)
• 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)
• yes (prop-subj-address-values)
• 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)
• no the thing reified by a topic is not a characteristic. (term-topic-characteristic-reified)
• Bare names. (xtm-href-xpointer)
• 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)
• 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)
• 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)
• 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)
• tnc is gone basically so i feel these defs are ok - if not yet perfect. (term-base-name-def)
• yes i think it is. (xtm-mergemap-reference)
• 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)
• 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)
• 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 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)
• 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)
• 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)
• 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)
• 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)
• probably not but we shouldnt enforce it. again maybe a warning if the processor deems it useful. (prop-subj-address-scope)
• 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)
• lose it. (term-theme)
• 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)
• 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)
• we should define it for completeness. As [with strings]: 0 elements and not null. (term-empty-set)
• I think that makes sense. (xtm-schema-uri)
• The DTD. (xtm-normative-schema)
• 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)
• 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)
• not our problem. (infinite-subject-spaces)
• 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)
• 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)
• i thought that maybe 'nameString' was better. (prop-value)
• 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)
• 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)
• 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)
• we could leave this one to be addressed by the conformance activity? (op-topic-map-compare)
• 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)
• 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)