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

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

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


Subject: [OASIS Issue Tracker] Commented: (ODATA-535) Define specialization for terms


    [ http://tools.oasis-open.org/issues/browse/ODATA-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=35075#action_35075 ] 

Ralf Handl commented on ODATA-535:
----------------------------------

@Mike: the current proposal omits using terms as types, see Note in the proposal. It also omits a required inheritance relation between the types of the base term and specialized term, it just allows optimization if an inheritance relation exists. Otherwise I wouldn't have been able to model the ScrumTeam as a specialization of the DevelopmentTeam.

@Martin: the proposal completely replaces our term Core.RequiresTerm. The other two terms for "can be cast to" are sketched as custom terms IsA and ItemIsA to make sure we can add them later. BaseTerm plus these two annotations covers all our use cases.

> Define specialization for terms
> -------------------------------
>
>                 Key: ODATA-535
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-535
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData CSDL, Vocabularies
>    Affects Versions: V4.0_CS01
>         Environment: [Proposed]
>            Reporter: Ralf Handl
>             Fix For: V4.0_CSD03
>
>
> When merging type terms and value terms we lost the possibility to define terms that are a specialization of other terms, e.g. "a developer is a person with programming skills".
> Given:
> - term Person using complex PersonType
> What we can currently do:
> - define a complex DeveloperType that inherits from PersonType
> - annotate something with term Person and use a record of type DeveloperType
> <Annotation Term="X.Person">
>   <Record Type="Y.DeveloperType">
>     <PropertyValue Property="Name" Path="Fullname" /> <!-- defined on PersonType -->
>     <PropertyValue Property="ProgrammingSkills" Path="ListOfSkills" /> <!-- defined on DeveloperType -->
>   </Record>
> </Annotation>
> So someone knowing the term Person will find this term with additional properties defined on the DeveloperType. 
> Drawback: no term "Developer"; semantic "is a developer" is expressed indirectly.
> Drawback: supports only one level. If an Architect is a special Developer, then the "is a developer" semantics is lost because the record's type is "Z.ArchitectType" and Y.DeveloperType is no longer mentioned in the annotation.
> Goals:
> - define a term Developer and indicate in the term definition that it specializes term Person
> - annotate something with term Developer in a way that someone knowing only Person and with no access to the definition of term Developer can recognize a Developer as a Person. This should also work with longer specialization chains
> Other use cases:
> - a Team is a collection of Person instances
> - a DevelopmentTeam is a Team, and also a collection of Developer instances
> - a ScrumTeam is a DevelopmentTeam with a ScrumMaster
> - a ScrumMaster is a Developer which is a Person

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


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