Graham Moore

Scoped Occurrences (43)

• 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)
• lose it. (term-theme)
• 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)
• 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)
• yes its allowed. if it doesnt validly ref something then tough luck. (xtm-href-whitespace)
• 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)
• not at all. this is well out of scope. (merge-use-of-schemas)
• Bare names. (xtm-href-xpointer)
• 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)
• 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)
• 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)
• 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)
• The DTD. (xtm-normative-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)
• 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)
• 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)
• not our problem. (infinite-subject-spaces)
• 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)
• 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)
• 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)
• 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 think that makes sense. (xtm-schema-uri)
• 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)
• 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)
• 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 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 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)
• 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)
• i thought that maybe 'nameString' was better. (prop-value)
• 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)
• 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 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 i think it is. (xtm-mergemap-reference)
• we should define it for completeness. As [with strings]: 0 elements and not null. (term-empty-set)
• yes (prop-subj-address-values)
• 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)
• 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 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)
• no the thing reified by a topic is not a characteristic. (term-topic-characteristic-reified)
• we could leave this one to be addressed by the conformance activity? (op-topic-map-compare)