Paul, FYI, in the Estimation spec we're adopting the design principle that the underlying data model aligns with RDF, which therefore influences the way you think of links. A simple link is a triple in which the object is a resource. The predicate gives the type of the link. If you need more information for the link then you are implicitly introducing another type of resource, which could have either a URI or be a blank node.
Arthur Ryman, IBM DE Chief Architect, Rational Project and Portfolio Management Office: 905-413-3077, Cell: 416-939-5063 Assistant: Nancy Barnes, 905-413-4182 Paul McMahan <[email protected]> Sent by: [email protected] 12/10/2009 11:48 AM To [email protected] cc John Whitfield <[email protected]>, [email protected] Subject Re: [OSLC] OSLC QM 1.0 specification There has been some discussion across the OSLC domains about the need for a common linking spec. Such a spec would likely have a major impact on the area of the QM spec pointed out because resource links have proven to be the most common occasion to use multi-valued properties in the C/ALM scenarios we have considered so far. The rdf example below demonstrates this as well. A common linking spec is not available at this time. So the CM approach was adopted for QM V1 with intentions to revisit for QM V2 when a linking spec might be available. But if the Estimation spec is already doing it the right way then the QM workgroup needs to take a closer look at it. I see that the RM V1 spec (not yet finalized) has taken a similar approach for linking, and the AM spec appears to be headed in that direction as well. Best wishes, Paul McMahan Rational Quality Management [email protected] Martin Nally/Raleigh/IBM To 12/09/2009 03:06 Paul McMahan/Raleigh/IBM@IBMUS, PM Arthur Ryman/Toronto/IBM@IBMCA cc [email protected], [email protected] , [email protected] Subject Re: [OSLC] OSLC QM 1.0 specification(Document link: Paul McMahan) This design adopts the design for multi-valued properties documented in the CM spec. I don't think this is a good design and we shouldn't propagate it. The OSLC estimation workgroup is doing this the "right" way, as shown in this example: <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; xmlns:dc="http://purl.org/dc/elements/1.1/"; xmlns:ems="http://open-services.net/software-metrics/";> <ems:Project rdf:about="http://braintwistors.example.com/ems/v1.0/Project/4201";> <dc:title>Tsunami 1.0</dc:title> <dc:description> The goal of ... </dc:description> ... <ems:hasEstimate rdf:resource=" http://braintwistors.example.com/ems/v1.0/Estmate/4203"; /> <ems:hasEstimate rdf:resource=" http://braintwistors.example.com/ems/v1.0/Estmate/4204"; /> ... <!-- other properties of this project resource have been omitted for brevity --> </ems:Project> </rdf:RDF> In other words, a multi-valued property is just what it says - a property with multiple values, as illustrated here by "ems:hasEstimate". You do not introduce a separate collection resource with separate link resources - that design is not in the spirit of REST, it's just an old-fashioned OO programming API exposed via http. Best regards, Martin Martin Nally, IBM Fellow CTO and VP, IBM Rational tel: (949)544-4691 |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Paul McMahan/Raleigh/IBM@IBMUS | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[email protected] | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Cc: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[email protected] | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |12/09/2009 12:05 PM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[OSLC] OSLC QM 1.0 specification | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Sent by: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[email protected] | >--------------------------------------------------------------------------------------------------------------------------------------------------| The OSLC Quality Management V1 specification is available at : http://open-services.net/bin/view/Main/QmSpecificationV1 I would like to thank the Quality Management workgroup members (BigLever, IBM, Sogeti, and Tieto) for their participation in the workgroup and contributions to the specification. The broader OSLC community is invited to view the specification and provide any feedback in the wiki or via the [email protected] mailing list. The Quality Management V2 specification effort is expected to get underway soon so any feedback on the V1 specification will be especially valuable. Best wishes. Paul McMahan Rational Quality Management [email protected] _______________________________________________ Community mailing list [email protected] http://open-services.net/mailman/listinfo/community_open-services.net _______________________________________________ Community mailing list [email protected] http://open-services.net/mailman/listinfo/community_open-services.net
