Topic Map Specifications | Customize | Filter | Export | Merge | Statistics | Google it! | Query | DB2TM | No schema | Edit | Vizigate | Not indexed

Kal Ahmed

Type(s): Person

Scoped Occurrences (5)

  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
Object id: 19
Item identifier(s):