[tmcl-wg] FYI: TMSchema presentation updated

[Dmitry]

On Mar 27, 2004, at 7:40 PM, Robert Barta wrote:

> On Sat, Mar 27, 2004 at 03:53:27PM -0500, Dmitry wrote:
>> I did several changes in TMSchema presentation:
>
>> http://homepage.mac.com/dmitryv/TopicMaps/TMCL/Lite/ 
>> TMSchemaPresentation/TMSchema.html
>
> Dmitry,
>
> Thanks for adding more text, I think I understand this now a bit
> better. Here are my comments:
>
> - You say "TM schema ... can be modelled in TM constructs".
>
>   Is this not true for ANY constraint language, and actually any
>   formal language? If I take, say, a Python (brrr :-) program, then
>
>   if False:
>      print "Python is cool"
>   else:
>      print "Oh, well"
>
>   The I can present this as TM construct like
>
>   (if-then-else)
>   if-branch   : code-123
>   else-branch : code-234
>
>   (is-sequence)
>   block: code-123
>   statement: print-345
>
>   ...
>
>   This also makes every such language accessible to introspection:
>
>   Give me all if-statements {in AsTMa?}:
>
>   forall $ifs [ (if-then-else) ]
>   return
>
>      {$ifs}

I think that there are different levels of modeling and introspection.  
I can just put TMPath "satisfies" predicate in occurrence and call it  
constraint, for example. One of the main ideas of TMSchema is to allow  
manipulating constraints as simple (data) structures.


> - Your external occurrences can be text. Maybe we should restrict them
>   to only hold URIs?

true


> - TMSchema is VERY verbose. And it suffers from the same problem as  
> tolog
>   in the sense that you cannot keep things together which belong  
> together:
>
>       baseNameSchema (composer, baseName, ....)
>       ...
>       baseNameSchema (composer, baseName/short, ...)
>
>   I HAVE to separate them into different clauses.
>

This is an example with LTM like syntax. I also have Python (or Relax  
NG compact) -like syntax.
TMSchema can support multiple syntaxes, it is an abstract notation.


>   On the other hand, is there a way to independently express the
>   cardinality and other aspects? Say, I want to constrain for basenames
>   that
>
>     (a) The value is a string of the form /some pattern/, or
>     (b) must be one of 'rumsti', 'ramsti' or 'romsti', or
>     (c) must have a particular data type

User can define multiple constraints but they are all combined  
(implicitly) with "and"

So I can say:

> (a) The value is a string of the form /some pattern/

> (b) must be one of 'rumsti', 'ramsti' or 'romsti',

TMSchema engine merges them all.


>   And how can I have 2 basenames with the same scope but the same  
> value?
>
> - TMSchema can only capture 'structural constraints', i.e. constraints
>   which constrain the form and content of topics and assocs. It cannot
>   constrain ontological information. Something like
>
>      'if a company is owned by something that something must be a
>      legal entity'
>
>   Is this correct?

playRoleSchema(company,object,is-owned-by,{roleSchema(owner,  
allPlayersFrom=[legalEntity] )})

OWL -like property restrictions are representable with TMSchema.

But TMSchema is oriented to representing structural ontological  
constraints. Complex constraints (like TMPath "satisfies") with full  
support for existence, and, or etc. is purpose of Schematron-like rule  
sub-language.

For rule sub-language there is no strong requirement for introspection.  
Rule merging does not include analyzing  of rules internal structures.   
Rules are used only for validation. But they can use full power of  
TMQL.


> - In
>
>       
> http://homepage.mac.com/dmitryv/TopicMaps/TMCL/Lite/ 
> TMSchemaPresentation/img21.html
>
>   you say that constraints should be part of the TM itself?
>
>   I think this is/was not a good idea for XML, so I wonder whether we
>   should introduce this dependency into TMCL. I can well imagine that
>   one and the same TM document can have several quite distinct TMCL
>   constraints. If one of them is somehow attached to the document,
>   this would introduce some asymmetry.
>

TMSchema constraints are part of topic map which has ontological  
information such as types, subtype-supertype
associations, type disjoint associations.

User can merge the same factual topic map with different "ontological"  
topic maps and test the same facts against different "theories"


> - In
>
>       
> http://homepage.mac.com/dmitryv/TopicMaps/TMCL/Lite/ 
> TMSchemaPresentation/img19.html
>
>   you suggest to use 'scope' for inferred information. The problem I
>   see is that this mixes the plane of the original content with that
>   of a derived one and this usually is asking for trouble.
>
>   The way I see this, is that an ontology O, when it is combined with a
>   map M to enrich it
>
>      O + M
>
>   forms a new map. All derived information is in that new map.
>
>   Whether that is now really created in a materialization event (as a
>   snapshot):
>
>      M' := O + M
>
>   or whether TMQL works on a 'virtual map' O + M and all the
>   inferences are created on the fly may depend on the data and the
>   necessary performance.
>
>

Scope allows me to see at the same time what user specified explicitly  
and what was deduced by engine.

I also look at inference as an incremental process. At the beginning I  
can have O+M but without any inferences.
Later, inference engine can add several assertions. For user it is "the  
same TM". Users modify the same TM,
run inference engine for some inferences, check conflicts, add  
exceptions, modify TM, run engine etc.


Dmitry