This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
MainOslcCommonArchitecture
>
ReportingHome
>
ModelingDataUC
(21 May 2010,
TackTong
)
(raw view)
<img alt="" src="file:///d:/temp/moz-screenshot-1.png" /><img alt="" src="file:///d:/temp/moz-screenshot-2.png" /><img alt="" src="file:///d:/temp/moz-screenshot-3.png" />Hey Arthur,<br /><br />thanks for the feedback. A couple of follow-up questions:<br /><br />>> For example, consider a tree hierarchary. Each node has links to its parent and child nodes. If you want all ancestors of a node, that's the transitive closure of the parent property. The ancestor property is a derived property that is maintained by the service, but you could use it in queries.<br />The scenario I have in mind is when a request for package and all its classes ( with all its attributes, methods etc) , diagrams, usecases etc is requested and then all its nested packages which in turn need all the classes ... Wouldn't the transitive closure loose the hierarchical structure needed for the output?<br /><br />One solution to shorten the request would be to specify the recursion level as an attribute of the query instead of duplicating the request. Ex: http://braintwistors.example.com/ems10/Project?oslc:properties=ems:service{dc:title}&oslc:recursion_depth=5<br /><br />>> The generic class issue could be handled using the RDF notion of class, i.e. that class is just an ordinary property rdf:type which is multi-valued.<br />Thinking out loud: would this mean that in the resource representation one could have all the properties of all the types referenced in the rdf:type for all the collection members? Would this be a new resource with its own resource shape which is the reunion of all properties? <br />One further question: would this be limited to homogenous collections? I don't think the server would have trouble creating heterogenous collections (ex: get all model elements with "x" in their names) but I'm trying to understand if this would be a valid and useful scenario and how would the reporting client handle it.<br /><br />Regards,<br /> Dragos<br /><br /><br /><br /><br />Arthur Ryman/Toronto/IBM@IBMCA<br />05/12/2010 10:53 PM <br /> To<br /> Dragos Cojocari/San Jose/Contr/IBM@IBMUS<br /> cc<br /> Benjamin Williams/UK/IBM@IBMGB, Nilesh Padmawar/Lowell/IBM@IBMUS, Tack Tong/Toronto/IBM@IBMCA, Ubaidu Peediakkal/Lowell/IBM@IBMUS<br /> Subject<br /> Re: OSLC Reporting for modelling data<br /> <br /> <br /> <br /> <br /><br />Dragos,<br /><br />Rhapsody and other software modelling tools manage resources whose structure is inherently recursive. The simple query languages we use don't handle recursion well. One way out is for these modelling tools to define derived properties which are effectively the transitive closure of relations. <br /><br />For example, consider a tree hierarchary. Each node has links to its parent and child nodes. If you want all ancestors of a node, that's the transitive closure of the parent property. The ancestor property is a derived property that is maintained by the service, but you could use it in queries.<br /><br />The generic class issue could be handled using the RDF notion of class, i.e. that class is just an ordinary property rdf:type which is multi-valued.<br /><br />Regards, <br />___________________________________________________________________________ Arthur Ryman, PhD, DE <br />Chief Architect, Project and Portfolio Management <br />IBM Software, Rational <br />Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 Twitter | Facebook | YouTube <br /> <br /><br /><br /><br /><br />From: Dragos Cojocari/San Jose/Contr/IBM@IBMUS<br />To: Arthur Ryman/Toronto/IBM@IBMCA, Tack Tong/Toronto/IBM<br />Cc: Benjamin Williams/UK/IBM, Nilesh Padmawar/Lowell/IBM@IBMUS, Ubaidu Peediakkal/Lowell/IBM<br />Date: 05/12/2010 08:27 AM<br />Subject: OSLC Reporting for modelling data<br /><br /><br />Hey Arthur, Tack,<br /><br />while implementing and using the RPE - Rhapsody integration we have ran into some issues that might be of interest in the context of OSLC Reporting Spec as well.<br /><br />Recursion and request size<br />For reporting Rhapsody exposes a single resource, which contains all the model data. The schema is quite large as it contains all the artifacts in the model. Using Insight's Reportable REST API it is possible to generate a single request to pull all the data for a report. Such a request will look like this:<br /><br />http://localhost:27463/Rational/Rhapsody?fields=Projects/Project/Components/Component/(additionalSources/label/userDefinedMetaClass/descriptionHTML/directoryName/buildType/standardHeaders/libraries/name/includePath/Configurations/Configuration/(additionalSources/label/descriptionHTML/directoryName/standardHeaders/libraries/timeModel/includePath/initializationCode/instrumentation/scopeType/statechartImplementation)/ComponentDiagrams/ComponentDiagram/(label/Pictures/Picture/(path)/ContainedElements/ModelElement/(label/userDefinedMetaClass))/PanelDiagrams/PanelDiagram/(label/Pictures/Picture/(path)/ContainedElements/ModelElement/(label/userDefinedMetaClass))/Dependencies/Dependency/DependsOn/ModelElement/(name))<br /><br />As you can see the URL is quite large and if more model data is requested it will get larger. But the real problem comes when recursion is needed. With the existing Reportable REST API recursion is achieved by duplicating the request in the URL. If recursion is on one of the top level elements ( such as packages) and those elements contain many other sub elements that need to be extracted the request will become extremely large. We have seen requests of 100.000 characters for common Rhapsody templates.<br /><br />The workaround in place is to allow large requests to be handled by the web server used by Rhapsody. However this is not the ideal solution. Looking at the OSLC Reporting Spec it seems that the same mechanism will be applied there and this will lead to the same problem.<br /><br />Generic resources and Casts <br />Another hot topic for the RPE-Rhapsody integration is the ability to use queries defined in Rhapsody. Given the large number of possible queries and even the possibility to add user defined ones prevents from having all the queries defined in the schema along with the type of the resource they return. What is missing is the ability to define a Query resource that returns a collection of ModelElement ( a generic type) and allow a "Cast" to the concrete type to be used in the Reporting Client. This will allow the schema to stay fairly small, allow to adopt new queries defined in one model or another and at the same time be able to fully process the result collection.<br /><br />We currently have this working in RPE for the Tau integration but the Reportable REST Spec does not support it.<br /><br />A similar problem I have tried to highlight in the usecase here: http://open-services.net/bin/view/Main/RSxUC <br /><br /><br />Let me know if the above descriptions are clear or further details are required.<br /><br />@Nilesh, Ubaidu - please fell free to correct me/add any items I might have missed.<br /><br />Regards,<br /> Dragos
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r1 - 21 May 2010 - 17:38:10 -
TackTong
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback