#########################################################################################
## This is a partial description of type 'composer'
## Can be 'merged' with other partial description of type 'composer'
## Some of the elements of the description can be inherited from type 'person'
## Some of them - can be 'deduced' from association and occurrence descriptions
##
## This is Python-like description
## I think also about new syntax for instances *.ptm :-)
## It will allow to do 'nested' descriptions like RDF does
##
## I added also association type 'born-in' description
##
## Link: Previous TMCL schema example
##
## 2004-01-16
##Copyright @ 2004 Dmitry Bogachev
##
#########################################################################################

## This sample is inspired by Ontopoia's OSL, Opera OSL schema and ... Pyhton syntax.
## 

## Type descriptions include several sections and subsections
## Each (sub)section has a meta-type and has a set of "properties" such as "cardMin", "datatype"
## So each type description is a well structured description. It can be easily modeled by some XML
## schema or InfoSet constructs.
## 
## Type description author does not need to provide "full" information about type. Based on
## superTypes  relationship schema engine can calculate default constraints 
## based on inheritance and other constraints. Author can confirm “deduced” 
## constraints, overwrite them or just do nothing and rely on “default” constraints.
## 
## At any moment schema engine can calculate combination of deduced and explicitly specified
## constrains.  Schema engine also can find explicit contradictions in structure-based constraints.
## For example: cardMin:5 and carMax:3 will produce a "conflict".
##
## Explicit type definitions overwrite "deduced" constraints.
##


## Declare default namespace for opera types. We can use "IDs" now.

declare default subjectIndicator namespace="http://psi.ontopia.net/opera-schema/#"

## Declare additional namespace for opera "facts". We may use it in "OneOf" constraints

declare subjectIndicator namespace o="http://psi.ontopia.net/opera/#"

## Declare XML-based datatypes, can be used in internal occurrences

declare datatypes xs="http://www.w3.org/2001/XMLSchema-datatypes"
                
object type composer:

    SuperTypes:
        musician

    Definitions:
        [musician; who[is-author-of]/what[music]]       

## TODO: Replace with OWL-like definition. 
## Existing def is more like a "sufficient rule" of being musician


    Schema-BaseName:
        *:
            cardMin=1
            cardMax=1

        *@normal:
            cardMin=1
            cardMax=1

        *@nom-de-plume:
            cardMin=1
            cardMax=1

        *@nom-de-plume,normal

    Schema-Occurrences:
        born:
            cardMin=1
            cardMax=1
            external=false

        died:
            external=false
            cardMin=1
            cardMax=1

        illustration:
            external=true
            cardMin=1
            cardMax=1

        article:
            external=true

        bio:
            external=true

        desc:
            external=true

        website:
            external=true

## we can use datatype constraints !!!  

            datatype="xsd:anyURI"


        homepage:
            external=true
            cardMin=1

        gallery:
            external=true

        snippet:
            external=true


        webPage:
             cardMin=1
             cardMax=1
             dataType="xsd:AnyURI"

    Schema-RolesInAssociations:

        who[born-in]:
            cardMin=1
            cardMax=1
            place:

## we can constrain 'other' role players, ~ of property restrictions in OWL 

                cardMin=1
                cardMax=1
                allValuesFrom=location

## This is another way to specify constraints for topic. 
## Engine "knows" that "bornIn" is a projection of born-in.
## Engine can rewrite projection constraints into associations role constraints

    Schema-BinaryProjections:
        bornIn:
            cardMin=1
            cardMax=1
            allValuesFrom=location
    

#########################################################################################
##
## This is a partial description of association type 'born-in'
##
#########################################################################################


association type born-in:
    transitive=false 

    role person:
        cardMin=1
        cardMax=1
        allValuesFrom=person

    role place: 
        cardMin=1 
        cardMax=1 
        allValuesFrom=place
    
## Projections can be used in TMQL 
## I think also to use projections during topic map authoring 

    projections: 
        bornIn: 
            transitive=false 
            orderedValues=false
            defQuery=$$self/roleOf::person@$$scope[born-in]/role::place 
            defAssert:
                 born-in@$$scope:
                     person=$$source
                     place=$$target
                          
        placeOfBirthFor: 
            transitive=false 
            orderedValues=false
            defQuery=$$self/roleOf::place@$$scope[born-in]/role::person
            defAssert:
                 born-in@$$scope:
                     person=$$target
                     place=$$source

## TODO: Projection description should be more declarative, kind of "arc" def. in XLink spec.
## Something like this:
##        bornIn: 
##            sourceRole=person
##            targetRole=place
##            transitive=false 
##            orderedValues=false
##            cardMin=1
##            cardMax=1
##            allValuesFrom=place
            

## Note 1:
## projection definition can have in fact to parts:
## - query (is used in queries)
## - assertion (set of TM assertions if I use projection for authoring)
##
## So If I say that (using new PTM format)
##
## topic JohnSmith:
##    displayName="John Smith"
##    bornIn=LondonUK
##
## engine will transform this statement into "normal" association
##
## Note 2:
## Projections also can have additional parameters. 
## It can be important for associations with arity >2
##
## Note 3:
## For binary associations order can be important. Example: authors list for paper.
## I think to have attribute 'orderedValues' for projections. 
## And standard variable $$position which can be used in "assert" statements. 
## We also need some standard way to represent ordered associations. 
##
## I like idea of Geir Ove Grønmo about 'position' 
## occurrence for 'person' scoped by reified association of type 'is-author-of'
##
## In query language (TMPath) new dynamic step 'position' should be available 
## for topics if topics are members of ordered value. Sequences keep order if order exists. 
##
## paper2003/hasAuthor 
## or 
## paper2003/work[is-author-of]/author
##       - returns authors in proper order
##
## If I need list in reverse order:
##
## let $t:=paper2003/work[is-author-of]/reifier
## for $author in paper2003/work[is-author-of]/author
## order by $author/position@$t desc
## return $author/fullName
## 
## topic paper-2004-01-20:
##     hasAuthor(1)=author1
##     hasAuthor(2)=author2:
##          fullName="John Smith"
##     hasAuthor(3)=author3
##
## OR
##
## topic paper-2004-01-20:
##     hasAuthor=sequence:
##         author1
##         author2:
##             fullName="John Smith"
##         author3
##
## This is the same as before. I just added additional "meta" info about hasAuthor values.
##
## topic paper-2004-01-20:
##     hasAuthor:
##         completeList=true
##         value=sequence:
##             author1
##             author2:
##                 fullName="John Smith"
##             author3
##