{paginate}
1 of 1
{/paginate}
Discussion on the draft OSLC Product specification
Posted: 26 May 2015 01:30 PM   Ignore ]  
Moderator
RankRank
Total Posts:  21
Joined  2012-10-01

The main scope of the Product specification was

Resources

A resource for Product

Related resources for Product Versions > This is now covered by the OSLC Configuration Management Spec

Related resource for Product Views (structure)

Properties

Properties for versioning > This is now covered by the OSLC Configuration Management Spec

Properties for associating Views with Products

Recommended usage of existing OSLC properties

Use of OSLC Core common properties - Title, Description

The proposal is that this draft needs to be updated to reflect the scope of the OSLC Configuration Management specification (draft)

Profile
 
Posted: 26 May 2015 01:55 PM   Ignore ]   [ # 1 ]  
Administrator
RankRank
Total Posts:  46
Joined  2015-03-23

The OASIS Configuration Management specification (and the Global Configuration Management capability that is part of IBM CLM 6.0), addresses how different tools can contribute configurations of versions of managed resources to a global configuration that can be used to maintain links across configurations.

That is a significant part of ALM. PLM also addresses the idea of products and product variants. Variants and versions have some similarities, but they also have significant differences. Versions and configurations of versions represent time sequenced changes to related resources over their lifecycle in order to achieve some outcome. Variants represent the instantiation of variability resulting from commonality/variability analysis done during development for and with reuse. Variants are versioned, but versions many not necessarily represent variants because they don’t have the facilities for formalizing or managing variation points (e.g., patterns and pattern instantiation).

From a broader perspective, PLM represents a more demand-side or domain specific view of lifecycle artifacts - what the requirements, change requests, test cases, designs, etc. are about from the perspective of specific stakeholders concerned with deliverables. As such, PLM may represent one of potential many different stakeholder viewpoints and supporting organizational structures of lifecycle data. A solution for PLM may benefit from considering this broader perspective, and perhaps support some general means of categorizing and organizing federated shared information that is flexible, open, and can be easily configured to support specific stakeholder needs.

Profile
 
Posted: 26 May 2015 05:11 PM   Ignore ]   [ # 2 ]  
Administrator
RankRank
Total Posts:  46
Joined  2015-03-23

I wonder if something like UML or SysML models, exposed as OSLC resources (in RDF) would be useful as a language for describing products and product configurations? It might be possible to develop an open-services.net or OASIS OSLC specification for a UML and/or SysML domains that could be used to describe complex systems and the relationships of their parts - including hardware and software.

Rational Software Architect and Rational Rhapsody Design Manager use this approach to enable OSLC linking between design models and other lifecycle artifacts.

Profile
 
Posted: 29 May 2015 01:50 PM   Ignore ]   [ # 3 ]  
New member
Rank
Total Posts:  1
Joined  2012-08-27

Jim - it is the goal of OSLC Configuration Management to not be limited to time-based versions. Variants are part of the scope. While the 1.0 draft does not address all the issues you mention, nor fully address notions such as effectivity, parametric variation, feature modeling, etc., future enhancements could do so. That’s not to say that additional specifications might not be needed - for example, it is not the intention for OSLC Configuration Management ever to describe the internal structure of the resources in a configuration, but only the graph of configurations of the components of a complex system.

Profile
 
Posted: 02 June 2015 06:09 AM   Ignore ]   [ # 4 ]  
New member
Avatar
Rank
Total Posts:  5
Joined  2013-08-29

Dear all:

Firstly, thank you very much for starting this thread to discuss about an OSLC Product Specification. I consider Gray has pointed out the main resources and properties that should be specified.

I would like to comment some ideas that could be interesting for this discussion. I understand that a product has different facets or views in different stages of development which data and information should be shared and exchanged.

From my point of view, a product can be seen at least from some perspectives: as a hierarchy structure (PBS) that is expected to contain the definition of the product and constraints (e.g. Sometimes is necessary to check some requirements that depend on aggregated values such as the mass), as an entity over which observations are generated (e.g. estimation and measurement metrics) and as an entity which contents and/or visualization should be shared.

I am currently working on how to share a PBS (using the W3C SKOS vocabulary, actually any xBS structure), how to align metrics to the components of a product (OSLC EMS and the W3C RDF Data Cube Vocabulary are the candidate specs.) and how to express contents and visualization (we are working on representing such data in a generic way). If you consider this approach interesting I will be very willing to share more information,

On the other hand, I would like also to add the next points:

-Regarding product versions, I agree that Configuration Management perfectly covers the need of managing versions. In addition, I would like to point out the W3C Provenance ontology [1] as a potential inspiring specification since it covers the concepts of agent, entity and activity that could be very useful to share information about a product (the entity). The main drawback is that this provenance model is quite verbose and it is not very used (as far as I know).

-I think the ISO STEP standards for exchanged product model data should be also considered to get inspiration on which data should be shared (I guess you perfectly already know this standard).

-Finally, I have been working in public procurement data (and supply chain in general) and public contracts must contain a description of contracts object. To do so, there is a lot of classifications (for different purposes statistics, etc.) that could be reused to give a multilingual description to the product such as the Common Procurement Vocabulary (CPV), UNSPSC, CPC,ISIC, NAICS, etc. I consider that product metadata should include also a link to these common classifications to ease the possibility of browsing a catalogue of products, linking the product to a supply chain management tool, etc.

I hope this can somehow contribute to the discussion about product specification and if I can contribute in other way just let me know,

Best regards,

[1] http://www.w3.org/TR/prov-o/

Signature 


Dr. Jose María Alvarez-Rodríguez
Visiting Professor
Knowledge Reuse Group
Carlos III University of Madrid
Tlfno: +34 916249115
WWW: http://www.josemalvarez.es
Skype: josem.alvarez

Profile
 
Posted: 31 July 2015 12:21 PM   Ignore ]   [ # 5 ]  
Moderator
RankRank
Total Posts:  21
Joined  2012-10-01

Hi Jose, welcome and thanks for your post - as we move to agree a scenario lets include these topics as we look at the information and service behaviour needed

On Item 2) STEP do you have something specific in mind ? or example of application today ?

The next meeting is August 24th which isn’t ideal for many in Europe but I expect us to shift onto the needed information to support the proposed scenario, which will be based upon the Edition 1 scenario that the community worked together upon. We’ve labelled the past wiki as “edition 1”.

Profile
 
Posted: 11 December 2015 12:39 PM   Ignore ]   [ # 6 ]  
Moderator
RankRank
Total Posts:  21
Joined  2012-10-01

Discussion on OSLC needs for Product resources

Topics on vocabulary for the discussion with the OASIS OSLC Core Technical Committee

Consideration on Resources

In considering the potential resource needs for the scenario we have considered the available vocabulary and from edition 1 considered those concepts already implemented, especially in the OSLC Configuration Management specification.

A first class resource for Product is proposed to provide a focus in the scenario The options for a resource appear to be:

1) define reference vocabulary for AM Resource and Linktype Specification

2) define a new 1st class Product resource for example under an oslc_product namespace

The options for basic properties could be:

1) Product reference identity e.g.unique product “number” , which of course may include coding via characters which yield something about type or lineage (MAY)

2) adopt properties from oslc_cm for e.g. status like Preliminary, Released, Withdrawn (MAY)

In terms of structure we have some options

1) use a Linked Data Platform Container and any resource inside is effectively a member of that view in this way we may form content from any resource

2) adopt properties for products composition e.g. consistsOf and contribution e.g. includedIn (MAY)

or indeed a combination of the two in which case consumers would need to distinguish between product individuals and products as containers of components

In terms of other relationships link predicates a number can be envisaged from the scenario

1) links from system elements (AM resources) to Product resources for functions to allocate to a product (MAY)

2) in some cases a link from product to system (AM) resources as realises (MAY)

3) existing predicates for instance specified from oslc_rm could be used from Product to Requirement or implementedBy or by validates from oslc_qm can also be used directly (MAY)

4) a predicate of affects from a Change Request is useful (MAY)

5) looking more widely such as when a physical asset such as for system integration and test is underway then a predicate to associate a product with an installed asset could be indicated by an instance predicate to an oslc_availability or oslc_reconciliation resource

The following diagram shows such concepts.

To be added

Additional notes from Edition 1: A resource type of Product Version and Product View were proposed, these are addressed by VersionResource and Configuration in the OSLC Configuration Management Spec.

Profile
 
   
{paginate}
1 of 1
{/paginate}