Topic Map Specifications | Filter | Export | Statistics | Query

Graham Moore

Type(s): Person

Scoped Occurrences (43)

  • 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)
  • 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)
  • yes its allowed. if it doesnt validly ref something then tough luck. (xtm-href-whitespace)
  • 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)
  • 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)
  • 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)
  • Bare names. (xtm-href-xpointer)
  • 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 (prop-subj-address-values)
  • 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)
  • 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 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)
  • i thought that maybe 'nameString' was better. (prop-value)
  • 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)
  • yes i think it is. (xtm-mergemap-reference)
  • 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)
  • lose it. (term-theme)
  • 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)
  • The DTD. (xtm-normative-schema)
  • no the thing reified by a topic is not a characteristic. (term-topic-characteristic-reified)
  • 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)
  • 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 at all. this is well out of scope. (merge-use-of-schemas)
  • 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)
  • 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 think that makes sense. (xtm-schema-uri)
  • 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)
  • 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 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)
  • we should define it for completeness. As [with strings]: 0 elements and not null. (term-empty-set)
  • 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)
  • 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 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • probably not but we shouldnt enforce it. again maybe a warning if the processor deems it useful. (prop-subj-address-scope)
  • 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)
Object id: 29
Item identifier(s):