Hey Arthur,

thanks for the feedback. A couple of follow-up questions:

>> 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.
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?

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

>> 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.
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?
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.

Regards,
Dragos




Arthur Ryman/Toronto/IBM@IBMCA
05/12/2010 10:53 PM
To
Dragos Cojocari/San Jose/Contr/IBM@IBMUS
cc
Benjamin Williams/UK/IBM@IBMGB, Nilesh Padmawar/Lowell/IBM@IBMUS, Tack Tong/Toronto/IBM@IBMCA, Ubaidu Peediakkal/Lowell/IBM@IBMUS
Subject
Re: OSLC Reporting for modelling data





Dragos,

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.

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.

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.

Regards,
___________________________________________________________________________ Arthur Ryman, PhD? , DE
Chief Architect, Project and Portfolio Management
IBM Software, Rational
Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 Twitter | Facebook | YouTube?





From: Dragos Cojocari/San Jose/Contr/IBM@IBMUS
To: Arthur Ryman/Toronto/IBM@IBMCA, Tack Tong/Toronto/IBM
Cc: Benjamin Williams/UK/IBM, Nilesh Padmawar/Lowell/IBM@IBMUS, Ubaidu Peediakkal/Lowell/IBM
Date: 05/12/2010 08:27 AM
Subject: OSLC Reporting for modelling data


Hey Arthur, Tack,

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.

Recursion and request size
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:

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))

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.

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.

Generic resources and Casts
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.

We currently have this working in RPE for the Tau integration but the Reportable REST Spec does not support it.

A similar problem I have tried to highlight in the usecase here: http://open-services.net/bin/view/Main/RSxUC


Let me know if the above descriptions are clear or further details are required.

@Nilesh, Ubaidu - please fell free to correct me/add any items I might have missed.

Regards,
Dragos