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

 View Only

  • 1.  Fw: [oslc-promcode] Version Control Commit by f-jiang

    Posted 01-27-2015 16:16
    Thanks for updating the shapes. The terms related to measurements should use the OSLC EMS vocabulary. The mapping is described in chart 4 of [1] [1] https://www.oasis-open.org/committees/download.php/54926/PROMCODE-EMS%202015-01-19.pptx _________________________________________________________ Arthur Ryman, PhD Distinguished Engineer Master Inventor Academy of Technology Chief Data Officer, Application Platform IBM Systems Middleware 905.413.3077 (phone) 416.939.5063 (cell) IBM InterConnect 2015 ----- Forwarded by Arthur Ryman/Toronto/IBM on 01/27/2015 11:04 AM ----- From: workgroup_mailer@lists.oasis-open.org To: oslc-promcode@lists.oasis-open.org Date: 01/27/2015 01:49 AM Subject: [oslc-promcode] Version Control Commit by f-jiang Sent by: <oslc-promcode@lists.oasis-open.org> Author: f-jiang Date: 2015-01-27 06:50:50 +0000 (Tue, 27 Jan 2015) New Revision: 61 Web View: https://tools.oasis-open.org/version-control/browse/wsvn/oslc-promcode/?rev=61&sc=1 Modified: shape/trunk/issueshape.ttl shape/trunk/measureshape.ttl Log: Add descriptions of Issue:stateOfIssue and Measure:typeOfMeasure * The descriptions of Issue:stateOfIssue and Measure:typeOfMeasure in our vocabulary document has been updated. Use this description in the shape turtle file as well. --------------------------------------------------------------------- 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


  • 2.  RE: [oslc-promcode] Version Control Commit by f-jiang

    Posted 01-28-2015 08:05
    If I understand correctly, we have following changes for shapes: * remove Measure and Measurement resources - and simply forget about MeasureType and UnitType as they were out of domain scope * use ems:metric instead of typeOfScope (Project?MeasureType) * change the range of unitOfScopeItemSize to ems:UnitOfMeasure * change the range of determines to ems:Measure They are trivial, but one question is: * What should we do for promcode:measures? - originally Measurement?Artifact and going to be ems:Measurement?promcode:Artifact. Can we really add this for resource defined in ems? - or define an inverted relation as promcode:Artifact?ems:Measurement ? - or define as inheritance promcode:Measurement <: ems:Measurement ?
    Original Message


  • 3.  RE: [oslc-promcode] Version Control Commit by f-jiang

    Posted 01-28-2015 14:00
    Funakoshi-san, Here are the changes we discussed last meeting: Replace the class promcode:Measure with ems:Measure. ems:Measure is therefore an external class, like foaf:Person. ems:Measure has the following properties: - dcterms:title, which corresponds to promcode:title - ems:metric, which corresponds to promcode:typeOfMeasure - ems:unitOfMeasure, which corresponds to promcode:unitOfMeasure - ems:numericValue, which corresponds to promcode:value Replace the class MeasureType with ems:Metric Replace the class UnitType with ems:UnitOfMeasure Replace the property promcode:observes with ems:observes (this links promcode:Measurement to ems:Measure). Yes, the range of promcode:determines is ems:Measure. No, do not replace promcode:Measurement by ems:Measurement at this time. They are very similar, but ems:Measurement is not an exact match for PROMCODE. However, even if we did adopt ems:Measurement it is OK to add more properties like promcode:measures. The list of properties we use goes into the Resource Shape that PROMCODE provides for each resource type. RDF is different than OO design in this respect. Leave promcode:measures as is. Also, I suggest the following name change. Rename promcode:typeOfScopeItemSize to promcode:scopeItemSizeMetric. This links promcode:Project to ems:Metric. We can be more precise here because ems:Metric has a subclass ems:SizeMetric. The range of promcode:scopeItemSizeMetric is ems:SizeMetric. We could add a subclass arrow from ems:SizeMetric to ems:Metric in the Domain Model diagram. _________________________________________________________ Arthur Ryman, PhD Distinguished Engineer Master Inventor Academy of Technology Chief Data Officer, Application Platform IBM Systems Middleware 905.413.3077 (phone) 416.939.5063 (cell) IBM InterConnect 2015 From: Kazuhiro Funakoshi <k-f@bk.jp.nec.com> To: Arthur Ryman/Toronto/IBM@IBMCA, "oslc-promcode@lists.oasis-open.org" <oslc-promcode@lists.oasis-open.org> Date: 01/28/2015 03:05 AM Subject: RE: [oslc-promcode] Version Control Commit by f-jiang Sent by: <oslc-promcode@lists.oasis-open.org> If I understand correctly, we have following changes for shapes: * remove Measure and Measurement resources - and simply forget about MeasureType and UnitType as they were out of domain scope * use ems:metric instead of typeOfScope (Project?MeasureType) * change the range of unitOfScopeItemSize to ems:UnitOfMeasure * change the range of determines to ems:Measure They are trivial, but one question is: * What should we do for promcode:measures? - originally Measurement?Artifact and going to be ems:Measurement? promcode:Artifact. Can we really add this for resource defined in ems? - or define an inverted relation as promcode:Artifact?ems:Measurement ? - or define as inheritance promcode:Measurement <: ems:Measurement ?
    Original Message


  • 4.  RE: [oslc-promcode] Version Control Commit by f-jiang

    Posted 01-29-2015 02:26
    Arthur, Thank your for summarizing the last discussion. It was great help. I have just updated shape documents except some unclear points. * Should we also add shapes for ems:Metric and ems:UnitOfMeasure? - originally, they were outside of our spec, so I didn't make shapes for them nor range definition to their inbound links - similarly on ems:Measure, but we had corresponding resource inside of our spec, so now we have its shape * Should we change to promcode:scopeItemSizeMetric? - your suggestion sounds reasonable in case if we include ems:Metric to the spec -- Kaz
    Original Message


  • 5.  RE: [oslc-promcode] Version Control Commit by f-jiang

    Posted 01-29-2015 16:38
    Kaz, You asked: > * Should we also add shapes for ems:Metric and ems:UnitOfMeasure? > - originally, they were outside of our spec, so I didn't make > shapes for them nor range definition to their inbound links We don't need shapes for ems:Metric and ems:UnitOfMeasure because they don't have any properties. They are just used to tag URIs as identifying metrics and units of measure. > - similarly on ems:Measure, but we had corresponding resource > inside of our spec, so now we have its shape > Yes, we need a shape for ems:Measure because it has four properties. > * Should we change to promcode:scopeItemSizeMetric? > - your suggestion sounds reasonable in case if we include > ems:Metric to the spec > Yes, I recommend that change but we should get agreement from the TC. Perhaps we can do this my email vote? -- Arthur Ryman


Related Content