Difference between revisions of "RIM based ITS"
Rene spronk (talk | contribs) |
|||
| Line 21: | Line 21: | ||
(Peter Hendler): If it comes true it would make communication between RIM based applications a lot less trouble. As you know, our MIF parsers and our meta classes add a lot of complexity to the reference Java SIG API and if we could just send messages already based on the RIM backbone that would be fantastic. If we wanted we could include the clone class names (optionally) as attributes. We wouldn't need them to process the messages and put them into a database but maybe they'd be nice for readability. Some humans might rather see "PrednisoneAdministration" rather than "ACT", but since they go into the ACT table the processing would be much easier if the message contained the information that a "PrednisoneAdministration" was a kind of ACT and belonged in the ACT table. | (Peter Hendler): If it comes true it would make communication between RIM based applications a lot less trouble. As you know, our MIF parsers and our meta classes add a lot of complexity to the reference Java SIG API and if we could just send messages already based on the RIM backbone that would be fantastic. If we wanted we could include the clone class names (optionally) as attributes. We wouldn't need them to process the messages and put them into a database but maybe they'd be nice for readability. Some humans might rather see "PrednisoneAdministration" rather than "ACT", but since they go into the ACT table the processing would be much easier if the message contained the information that a "PrednisoneAdministration" was a kind of ACT and belonged in the ACT table. | ||
| + | |||
| + | The code displayName attribute of an Act could cary the "PrednisonAdministration" string. --[[User:Michael.vanderzel|Michael]] 11:13, 17 April 2009 (UTC) | ||
| + | |||
| + | In a pure (backbone) RIM ITS I would like to see elements named Act, ActRelationship, Participation, Role, RoleLink and Entity. We could even make a RIM ITS witch would have the backbone names plus Employee, Observation, etc. --[[User:Michael.vanderzel|Michael]] 11:13, 17 April 2009 (UTC) | ||
==Transformation between the XML ITS R1 and the newly proposed RS XML ITS (MS-RS cell transition)== | ==Transformation between the XML ITS R1 and the newly proposed RS XML ITS (MS-RS cell transition)== | ||
*to match the rim object graph to a specific rim model (i.e. an HMD) (which is required to serialise in that form), you must match the elements to the model by running validation in reverse - it is this kind of association because it meets the constraints that this association has. And you need the MIF for that, of course | *to match the rim object graph to a specific rim model (i.e. an HMD) (which is required to serialise in that form), you must match the elements to the model by running validation in reverse - it is this kind of association because it meets the constraints that this association has. And you need the MIF for that, of course | ||
Revision as of 11:13, 17 April 2009
The RIM based ITS (or RS XML ITS, a term used by the RIMBAA WG) is an ITS that is based on 'pure RIM semantics', i.e. an ITS that defines an XML syntax which allows for the XML to be processed solely based on its contents (and not on Class Clone names, or knowledge of templates/interactions used).
We currently have the XML ITS R1. It has the following properties:
- element names identify Rim clone classes
- properties that are defaulted in the Rim specific model (CIM) are not represented in the instance
- the order of associations in the instance is fixed for predictability - based on element names
- whether something is play or scoper etc is implicit (in the rim specific model) rather than in the instance
- You need the MIF to convert from the instance to a general RIM graph.
The RIM serialization would have different properties:
- element names identify the RIM back bone associations
- properties that are defaulted in the general rim are not represented in the instance
- Almost all structured attributes (e.g. classCode, moodCode) will be present in all instances
- the order of the associations is irrelevant: only their semantics matter
- player/scoper etc is explicit in the instance
Analysis
Characteristics of instances that conform to this ITS
- The XML element names (related to classNames, not attribute names) only serve to provide a syntax, they carry no semantics, and are not used in determining the semantics of the artefact content.
(Peter Hendler): If it comes true it would make communication between RIM based applications a lot less trouble. As you know, our MIF parsers and our meta classes add a lot of complexity to the reference Java SIG API and if we could just send messages already based on the RIM backbone that would be fantastic. If we wanted we could include the clone class names (optionally) as attributes. We wouldn't need them to process the messages and put them into a database but maybe they'd be nice for readability. Some humans might rather see "PrednisoneAdministration" rather than "ACT", but since they go into the ACT table the processing would be much easier if the message contained the information that a "PrednisoneAdministration" was a kind of ACT and belonged in the ACT table.
The code displayName attribute of an Act could cary the "PrednisonAdministration" string. --Michael 11:13, 17 April 2009 (UTC)
In a pure (backbone) RIM ITS I would like to see elements named Act, ActRelationship, Participation, Role, RoleLink and Entity. We could even make a RIM ITS witch would have the backbone names plus Employee, Observation, etc. --Michael 11:13, 17 April 2009 (UTC)
Transformation between the XML ITS R1 and the newly proposed RS XML ITS (MS-RS cell transition)
- to match the rim object graph to a specific rim model (i.e. an HMD) (which is required to serialise in that form), you must match the elements to the model by running validation in reverse - it is this kind of association because it meets the constraints that this association has. And you need the MIF for that, of course
