Mapping topic map schemas to schema level predicates
I am playing with Prolog implementation of TMSchema
now...
I try to understand relationships between different
TMCL levels.
Firstly, I use schema
terms to represent schema. It looks something like this:
schema::topic(musician,
[
....baseName(fullName,
....[
........cardMin(1),
........cardMax(1)
....]),
....internalOccurrence(age,
....[
........cardMin(1),
........cardMax(1),
........dataType("xsd:nonNegativeInteger")
....]),
....externalOccurrence(webPage,
....[
........cardMin(1),
........cardMax(1),
........match(".\.com")
....]),
....playRole(who,born-in,
....[
........cardMin(1),
........cardMax(1),
........otherRole(where,
........[
............cardMin(1),
............cardMax(1),
.............allPlayersFrom([location])
........])
....])
]).
Of
course, it is possible to have several schemas for the same
type-topic.
I translate these schemas
to schema level predicates.
It looks
something like
this:
constraint::every(musician,
baseName(fullName),relevant)
constraint::every(musician,
baseName(fullName),cardMin(1))
constraint::every(musician,
baseName(fullName),cardMax(1))
constraint::every(musician,internalOccurrence(age),relevant))
constraint::every(musician,internalOccurrence(age),cardMin(1))
constraint::every(musician,internalOccurrence(age),cardMax(1))
constraint::every(musician,internalOccurrence(age),dataType("xsd:nonNegativeInteger"))
...
constraint::every(musician,playRole(who,born_in),
relevant)
constraint::every(musician,playRole(who,born_in),
cardMin(1))
constraint::every(musician,playRole(who,born_in),
cardMax(1))
constraint::every(musician,otherRole(who,born_in,where),
relevant)
constraint::every(musician,otherRole(who,born_in,where),
cardMin(1))
constraint::every(musician,otherRole(who,born_in,where),
cardMax(1))
constraint::every(musician,otherRole(who,born_in,where),allPlayersFrom([location]))
Each constraint should also have some
metadata, of course, to keep track of information
origin.
It is easy to merge these
schema predicates. They also have very good
introspection.
We also can formally
specify validation meaning for each of
them.
For example (using
pseudocode),
validate(constraint::every(TypeTopic,
playsRole(Role,A), cardMin(N))):-
every
X in X : TypeTopic satisfies
atLeast
N Y satisfies
association(Y,A),playsRole(X,Role,Y).
Posted at 02:35 PM
Read More
Extending "rule" part of TMCL
I think that TMCL-Rule should support several
additional constraint patterns.
Current TMCL straw man proposal includes only rules
like this:
every X in P(X) satisfies
Q(X)
I think it makes sense to include
several additional "constraint patterns" such
as:
some X in P(X) satisfies
Q(X)
some X satisfies
Q(X)
atLeast N Y in P(Y) satisfies
Q(Y)
atLeast N Y satisfies
Q(Y)
atMost N Y in P(Y) satisfies
Q(Y)
atMost N Y satisfies
Q(Y)
satisfies P (example: satisfies
count(X: document)>20
)
atLeast
and
atMost meta predicates are very helpful for
cardinality constraints.
They are
expressible using "count" function, but it is better to have them explicitly in
a standard, I think.
Of course, we are
going to use complex rules only for validation (of specific topic maps).
But we can try different validation
scenarios, for example:
- validate topic map
TM with constraint set C1 and C2
- validate
topic map TM with constraint set C1 or
C2
We also can reuse Schematron idea of
"phases". In topic maps it closely corresponds to idea of
scopes.
So we can do something like
this:
-validate topic map TM with
constraint set C in scope S
I think value of this "rule based"
approach (as opposite to "Description Logic Only" approach) will be recognized
more and more in future (specifically in business
environment).
Validation rules
(together with "virtual Topic Maps") will allow to implement near real-time
monitoring of enterprise information resources.
I also hope that TMCL will support
explicitly concept of conflicts. So TMCL-based systems will have a standard way
to report about "problems". Combined
with Topic Maps universal data
model it will create very powerful standard-based
solution.
Think about hundreds of
different small and big proprietary compliance systems and reports which each
enterprise has.
Posted at 02:29 PM
Read More
TMSchema presentation update
I did several changes in TMSchema
presentation:
1) I introduced concept
of explicit exceptions for restricting schema
propagation
2) User defined schemas and
results of schema inference are now available for
querying.
I use [deduced,proposal] and
[deduced,result] scopes to represent inference
results
3) PDF version is
available
Posted at 12:48 PM
Read More
TMSchema - TMCL Lite proposal
TMSchema supports simple validations and
introspection. It defines concept of partial descriptions and schema merging.
Conflict identification and resolution are important parts of
TMSchema.
Posted at 02:58 PM
Read More
Implementing TMCL Lite using Topic Maps
I tried to implement concept of Partial Type
Descriptions (PTD) using topic maps.
Originally I used OO notation to describe main PTDs
ideas. Link.
This time I introduce TMSchema
topic map which allows to describe PTDs as topic map constructs and sample
TMSchema based on Opera topic
map.Instructions for sample usage can
be found here.I
think this example illustrates that important constraints can be represented as
schemas using topic map technology. I am going to concentrate on "engine" part
now. Key ideas include schema inheritance and merging (combining constraints).
Posted at 08:40 PM
Read More
TMCL Lite and Partial Type Descriptions
I tried to organize some of my thoughts about TMCL
Lite.
Key concept is Partial Type
Description (PTD). PTDs are based on predefined set of
constraints.
Several PTDs can be combined
into one type schema...
Posted at 02:11 PM
Read More
TMCL Lite - Python style
This example uses Python style for describing TMCL
schemas
Posted at 10:03 PM
Read More
Compact TMCL-Lite: investigating ideas
Link: Sample
of possible compact syntax for TMCL-Lite
Actually, it is not a real "syntax". I try to find a
way to define type schema and add
constraints.
It is an example of "partial"
type description. This kind of descriptions can be easily combined...
Posted at 01:20 AM
Read More