OSLC Lifecycle Integration for Project Mgmt of Contracted Delivery (PROMCODE) TC

TC Members, I reviewed the proposed change from two weeks ago. [1] You added "unit of measure" to Measure, which is good. However you propose to use strings instead of URIs to identify the unit of measure: "- Unit is a String type for light weight usage. URI seems a little too strict for our usage." This can lead to problems. At OSLC and in IBM Rational we have found that when we allow people to use a string as the value of an attribute, e.g. for work item severity or priority, then everyone uses something different. This makes it very difficult to write queries that combine data from projects that come from different teams or organizations, speaking possibly different languages. In the OSLC CM V3.0 spec, new URIs are defined for priority and severity. [2] In general, it is useful to define standard URIs for important concepts, and to precisely define these concepts in a vocabulary document. That is how the OSLC EMS specification handles units of measure. Recall that the first principle of Linked Data is to use URIs as names for things. [3] [1] https://www.oasis-open.org/apps/org/workgroup/oslc-promcode/download.php/53645/meeting-note-07232014.doc [2] http://open-services.net/wiki/change-management/Specification-3.0/#Resource_Severity [3] http://www.w3.org/DesignIssues/LinkedData.html Regards, ___________________________________________________________________________ Arthur Ryman, PhD Chief Data Officer, Rational Chief Architect, Portfolio & Strategy Management Distinguished Engineer Master Inventor Academy of Technology Toronto Lab +1-905-413-3077 (office) +1-416-939-5063 (mobile)

Hi Arthur, Thank you for your comment. After we have discussed about this topic, we are now thinking that using URI instead of String might be a better way. We also think that rdf:type will be used instead of dcterms:type to express the extended type of each resource type in PROMCODE. For example, if a user wants to use a Measure with type="code size" and the unit="kloc". The resource can be expressed like: <promcode:Measure> <rdf:type rdf:resource=" http://aaa.com/pm#CodeSize"/ > <promocode:unit rdf:resource=" http://aaa.com/pm#Kloc"/ > ... </promcode:Measure> The resource has two rdf types Measure and CodeSize so that the client can understand the actual meaning of the resource. The same usage of rdf:type will be used for other types like ScopeItem. Please let us know your thought. We are still discussing this topic and would like to get the final decision at the next call on August 19. regards Masaki Wakao (?? ??) STSM, Rational Development, Tokyo Software Development Laboratory, SWG, IBM E-Mail: wakao@jp.ibm.com Phone: 080-6706-8299 (Tie: 206-8299)

Wakao-san, Yes, using URIs for the metric and the units is more aligned with Linked Data design principles. I believe that are now less differences between PROMCODE and EMS. The OSLC EMS spec defines URIs for units of measure and other related concepts. See [1]. I recommend that PROMCODE use those URIs and the associated EMS vocabulary terms. At the next meeting I will describe the OSLC EMS vocabulary. EMS defines many types of metrics. In your example, you are measuring size. ems:SizeMetric is the class of size metrics. It contains the metric metric:Sloc for source lines of code (SLOC). The other size metrics are Effective SLOC, Function Points, Story Points, Use Case Points, and Ideal Days. Other types of size metric can be defined. You can measure SLOC in lines of loc (unit:Loc), and thousand lines of code (unit:Kloc). EMS defines the type ems:Measure [2]. Suppose that a UI module has 5 KLOC. In EMS the RDF in Turtle is: <#ui-module-sloc-measure> a ems:Measure ; dcterms:title "Source lines of code size of UI module measured in KLOC" ; ems:metric metric:Sloc ; ems:unitOfMeasure unit:Kloc ; ems:numericValue 5 . The benefit of PROMCODE adopting terms from EMS is that other OSLC specifications also may use measurement concepts. It makes sense for all OSLC specifications to use a common vocabulary. For example, OSLC Performance Monitoring has adopted EMS. See [3]. EMS has been in the Convergence stage for a long time. We need to get more feedback from other specifications. This means that if PROMCODE has other requirements, we can modify EMS. [1] http://open-services.net/wiki/estimation-and-measurement/EMS-1.0-REST-API-Standard-URIs/ [2] http://open-services.net/bin/view/Main/MetricsEmsMeasure [3] http://open-services.net/wiki/performance-monitoring/OSLC-Performance-Monitoring-Specification-Version-2.0/#Resource.3A-ems.3AMeasure Regards, ___________________________________________________________________________ Arthur Ryman, PhD Chief Data Officer, Rational Chief Architect, Portfolio & Strategy Management Distinguished Engineer Master Inventor Academy of Technology Toronto Lab +1-905-413-3077 (office) +1-416-939-5063 (mobile) From: Masaki Wakao <WAKAO@jp.ibm.com> To: oslc-promcode@lists.oasis-open.org, Date: 08/13/2014 02:21 AM Subject: Re: [oslc-promcode] Comments on Proposed Change to Measure Sent by: <oslc-promcode@lists.oasis-open.org> Hi Arthur, Thank you for your comment. After we have discussed about this topic, we are now thinking that using URI instead of String might be a better way. We also think that rdf:type will be used instead of dcterms:type to express the extended type of each resource type in PROMCODE. For example, if a user wants to use a Measure with type="code size" and the unit="kloc". The resource can be expressed like: <promcode:Measure> <rdf:type rdf:resource=" http://aaa.com/pm#CodeSize"/ > <promocode:unit rdf:resource=" http://aaa.com/pm#Kloc"/ > ... </promcode:Measure> The resource has two rdf types Measure and CodeSize so that the client can understand the actual meaning of the resource. The same usage of rdf:type will be used for other types like ScopeItem. Please let us know your thought. We are still discussing this topic and would like to get the final decision at the next call on August 19. regards Masaki Wakao (?? ??) STSM, Rational Development, Tokyo Software Development Laboratory, SWG, IBM E-Mail: wakao@jp.ibm.com Phone: 080-6706-8299 (Tie: 206-8299) --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php