OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [topicmaps-comment] Ontopia Schema Language (Tutorial), Feedback


Hi Lars,

I had a look at your schema language (Ontopia Schema Language, OSL) and have 
following comments/suggestions:

Tutorial:

  - do I understand it correctly, that OSL does constraining on an topic class/pattern
    and assoc class basis? What about 'global constraints' like : "There must be a least
    one composer in the map!"

  - 2.1 ..until a constraint matching __the__ characteristic...

    Not quite clear which one is meant here.

  - 2.1 Generally, ....which have no type__,__scope....

    Add ,, but this whole paragraph is a bit unclear to me.

  - 2.1 Table:

    Maybe swap the columns and reorder them to

        Containee    Container Element .....

    Maybe add more explanation to 'Element' such as '...is used to express...'

  - 2.1 Note that a topic map sche.........not contain any topic definitions __or association definitions__.

  - 2.1 I think I understand the rationale for internalTopicRef but is is somehow not pretty.

    What this shows is that (a) the TMCL and (b) the TMQL  __has to have__ some connection
    to the maps it constrains. They have to share the same ontology which is a circular
    thing as contraints define ontologies.

    This is something we have to think harder about because it directly affects the management
    of maps, constraints, queries in our software.

  - 2.2 ...you can find in the .... directory.

    Of what? I guess it is the Ontopia starter kit, but, well ....

  - 2.2 ...using the validation errors we get to improve __iteratively__ the schema.

    Suggest: add

  - 2.2 Typo: We start of__f__

  - general: can labels of code be underneath the code instead of above? This looks so
    much like a heading to me.

  - general: Maybe not use colloqial we'll, it's, we'd, can't but its long form 'we will', ...

  - 2.2 'empty standard class'

    Would it hurt to add the <tm-schema> .... </tm-schema> tags? It makes it clear where
    the constraint should be put.

  - 2.2 'empty standard class'

    What is exactly the meaning: Is it "this rule will match if a topic has

        - EXACTLY and ONLY this type,
        - AT LEAST this type

    I'm not talking about the subclasses thing.

  - 2.2 suggest to replace 'caring' by 'bothering'

  - 2.2 ....but this will then depend on where the map is located

    The topicRef element 'does not depend' on the location, the
    href attribute would include that.

  - 2.2 ....374 errors.....

    If the example map grows the value will be different.

  - 2.2 <scope></scope>

    Why exactly should someone write this? Every characteristic is either in a scope
    or in the unconstrained scope. If I leave it away does it mean 'I do not care',
    then?

  - 2.2 <occurrence external....

    Where to put this? I guess inside the topic?

  - 2.2 ....allow topics of class standard to have occurrences of these four types

    ONLY of these four? Or AT LEAST of these?

  - 2.2 ....also supports association class definitions __.__

    Add '.'

  - 2.2 ....strict matching.....

    There has not been any reference to 'strict' at this point. It is only defined
    in the specification document.

Good reading. I'll go through the spec now.

\rho



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC