[sc34wg3] new working draft of 13250-5 (Reference Model)

[Robert Barta]

On Mon, Nov 08, 2004 at 10:30:26AM -0500, Steven R. Newcomb wrote:
> A new working draft of 13250-5, "Topic Maps - Reference Model",
> is now available at http://www.jtc1sc34.org/repository/0554.htm
> 
> It's significantly shorter, and we hope and believe it's easier to
> understand, too.

Patrick, Steve,

I have some questions/comments/etc...

  - Compared to the earlier version a topic map is now

    "set of subject proxies"

    This means that any connections, such as assertions between
    subject proxies are NOT part of a map. I assume (more precise,
    guess) that this is because it is a TMA which has to come
    up with properties (classes, ....). Only with these it is possible
    to connect proxies. Correct?

    If so, then what is a map more than a skeleton of proxies?
    This also means that a map cannot contain any data itself,
    only views can have it?

  - I also observe that you moved away from assertions to properties.

    I assume that the idea is that everyone can build his own way
    to connect things?

    As it stands, this can be done for TMDM-level associations in the
    same way as for RDF triples.

    That, by itself is ok, but then I ask where is the
    topicmappishness? Specifically the unique way how TMs is connecting
    things with letting them play roles?

  - While I have my doubts of the usefulness of an EBNF to characterize
    a TMA, it has given some insights how you imagine the process.

    - is the topicMapAppName relevant? Whenever I define a name, I also
      have to define the namespace the name is in.

    - would it be possible to collapse OPs and SIPs definitions by allowing
      the propertyInstanceSubjectSamenessDetectionRule (people have been killed
      for creating names like these :-) to be optional in case of OPs?

    - is the topicMapAppName relevant in the PInstances?

    - experimenting with the grammar I got:

(1) topicMapApplicationDisclosure = (propertyClassDefinition*)


(2) propertyClassDefinition = ( ClassDefinition | conferralDefinition )


(3) ClassDefinition = (propertyClassName,
                       propertyValueConstraints,
                       propertyInstanceMergingRule,
                       propertyInstanceSubjectSamenessDetectionRule?)

(3') conferralDefinition = (propertyClassName, conferralRule)


(4) subjectProxy = (PInstance+ )

(5) PInstance = (propertyClassName,
                 propertyValue)


(8) topicMapView = (subjectProxy*)


      Rules 1,2,3 and 3' look EXACTLY as if they would belong to an
      ontology definition language.

      Rules 4,5,8 look dangerously close to RDF. Not sure what this means.

  - Barta/Salzer's \Tau model is not really an implementation strategy.

  - 1 (Scope):

    4. The supporting algorithms and data models that may be used to
    represent subjects, to detect when two or more subject proxies are
    proxies for the same subject, or to merge the values of Subject
    Identity Properties or Other Properties.

    Is it 'represent subjects' or 'represent subject proxies'?

  - 2 (Glossary).

    Maybe use 'native' instead of 'built-in'?

  - 2.2 conferred

    The sentence 'Existing because of the operation of a conferral rule...' is pretty cryptic to me.

  - in 2.3 I find

    "Optionally, a disclosure may also define one or more interchange
    syntaxes, data models, implementations, and/or implementation
    strategies, along with unambiguous and comprehensive instructions as
    to how instances of each such syntax, data model, etc. are intended to
    be interpreted in terms of the defined Topic Map Application."

    but these things do not appear in the EBNF grammar.

  - in 2.7 (property instances) it says

    "In the subject proxy in which it appears, it is the only instance of its class."

    I read this as saying that a subject proxy can have a property of a class attached.
    But why is this limited to one of its class? Why not allow a proxy
    to have 2 shoe sizes? Is it because in 2.10 it say in the note:

    "The value of an SIP or OP may be a single value, or it may have multiple named and/or unnamed components".

    ?

  - in 2.12 (topic map) it says:

    "An document written in a topic map syntax".

    Is an XTM file really a topic map?

  - 3 (Subjects and Subject Proxies)

    The last two paragraphs are very vague to me. Saying things like
    "...can provide a useful basis..." is a bit vague.

  - 4.4 Property Instance Merging Rules

    Is it a constraint that if one merges two properties of the same
    class, that the values have to be merged into a new value? Must
    it be a value of the same class?

    "...violate the logic of a TMA..."

    What exactly does that mean?

  - 4.6 is a bit vague to me as well :-)

Overall the new TMRM looks very lean to me. Not sure how good this is
;-)

\rho