-- GrayBachelor - 10 Aug 2011

Proposal for OSLC Spec 2.0 extensions to support PLM behavior

Draft for feedback

Versioning (or more correctly, Version Progression Linking) Proposal

This is a proposed approach to version progression linking that will allow OSLC to handle versions is a similar fashion to STEP (ISO-10303) Product->Product Version structures used in PLM.

Key Considerations

Some key considerations that have shaped this proposal:

• URI's should not be structured or intelligent in any way, so the version is not implied or inferred by anything in the URI. In fact, the top Product resource could have a completely different base URI (server) from any or all of its Product Versions.
• Use core concepts already defined by Web standards if they exist
• Provide abilty to have multiple active versions simultaneously defined, to support notions of "branching" and "merging" as they exist in many SCM systems.
• Frame the proposal in a way that it will fit into the OSLC Core specification, thus applying to all domain specifications in the same way.
• Make the proposed approach compatible with PLM concepts, and compatible with the proposed approach for Product Context (Product View Definition)

It is important to note that this proposal uses the term "version" to match the meaning defined in the STEP standards, specifically this description of the Product_version entity from ISO-10303:1018-2004:

A Product_version is  a revision of a Product. It is a collector of the definitions of this revision of the Product. 

NOTE  The set of all instances of *Product_version* of the same *Product* represents the history of the product.  

This definition does not specify any particular rules for when versions are created, how often they are created, or the specific semantics of their use. The only requirement is that the entire history (for some purpose) of the Product (Resource) can be described as the set of all versions. If the particular application or provider only preserves the state of a version at the instant the resource is POSTed or PUT to the provider, then the state of the version may change at each such save event, and the history of those incremental saves is not necessarily guaranteed or intended to be preserved. If the resource URI changes, the provider SHOULD expect that this resource state represents a new version, but in certain situations this may not be appropriate or required. This approach allows numerous URI encoded storage schemes to coexist as long as the notion of version is properly mapped to that scheme. Scenarios to illustrate some mappings for popular providers should be developed.

Text to be Added to the OSLC Core Specification

Under " Creating an OSLC Defined Resource ", add a second paragraph:

For resources that are always intended to be versioned, creating a new resource includes creating the first version of the resource as well as a "base" resource to serve as the entry point to all of its versions. Providers MUST recognize if a resource is a new versioned resource or a new version of an existing "base" resource, and act accordingly. If the resource being created includes a non-null "replaces" property, it MAY omit the "isVersionOf" property/value and the provider MUST get the link to the "base" version from the resource pointed to by the "replaces" property. If both non-null "replaces" and "isVersionOf" properties are given, the contents of the "isVersionOf" property SHOULD be checked against the contents of the "isVersionOf" property on the resource (version) pointed to by the "replaces" property value; if they do not match then the provider SHOULD return an error and refuse to create the resource.

A consumer or provider SHOULD interpret a resource having one or more "hasVersion" properties with non-null values as a "base" resource of its type, and act accordingly to validate the other content of that resource based on the semantics defined by the governing OSLC domain specifcation. Conversely, a consumer or provider SHOULD interpret a resource having an "isVersionOf" property with non-null values as a version of a "base" resource. Any resource MUST NOT have both an "isVersionOf" and a "hasVersion" property with non-null values.

In " Core Specification Appendix A: Common Properties ", under " Dublin Core Properties ", append the following lines (except the top line, copied here for reference) to the table:

Prefixed Name	Read-only	Value-type	Representation	Range	Description
dcterms:isVersionOf	unspecified	Either Resource or Local Resource	Either Reference or Inline	resource of same type	A related resource of which the described resource is a version, edition, or adaptation. OSLC usage requires the target resource MUST be a resource of the same type as the owning resource.
dcterms:hasVersion	unspecified	Either Resource or Local Resource	Either Reference or Inline	resource of same type	A related resource that is a version, edition, or adaptation of the described resource. OSLC usage requires the target resource MUST be a resource of the same type as the owning resource.
dcterms:replaces	unspecified	Either Resource or Local Resource	Either Reference or Inline	resource of same type	A related resource that is supplanted, displaced, or superseded by the described resource. OSLC usage requires the target resource MUST be a resource of the same type as the owning resource.

RDF Examples

The following examples illustrate how the version progression linking would look as it applies to a Requirement resource set. The approach is intended to apply at the Core resource level so all other OSLC domain specific resources SHOULD inherit the same capabilities. Requirement 46 (in file req_46.xml) is the "base" resource of all versions. Requirement 45 (in file req_45.xml) is a version of that Requirement. Requirement 49 (in the file req_49.xml) is another version of Requirement 46, which was created from Requirement 45, thus being a "later" version of that requirement. Note that all versions of Requirement 46 are linked from there by the dcterms:hasVersion tag, so a provider MUST update the base resource whenever a new version of it is created. This approach lets consumers get the base resource and traverse from there to get any of the versions of the resource that exist.

• Validate RDF: req_45.xml

<rdf:RDF
   xmlns:oslc_rm="http://open-services.net/ns/rm#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:oslc="http://open-services.net/ns/core#"
   xmlns:dcterms="http://purl.org/dc/terms/"
   xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">
<oslc_rm:Requirement rdf:about="http://localhost:8082/rio-rm/requirement/45">
   <rdf:type rdf:resource="http://open-services.net/ns/am#Resource"/>
   <dcterms:title>EU MarketRegion</dcterms:title>
   <dcterms:description>The product shall be marketable in the European Union (EU) geopolitical region.</dcterms:description>
   <dcterms:identifier>45</dcterms:identifier>
   <dcterms:modified rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2011-06-28T17:10:58.612-04:00</dcterms:modified>
   <dcterms:created rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2011-06-28T17:10:51.253-04:00</dcterms:created>
   <dcterms:creator rdf:resource="http://localhost:8082/rio-rm/user/_UNKNOWN_USER_"/>
   <dcterms:contributor rdf:resource="http://localhost:8082/rio-rm/user/_UNKNOWN_USER_"/>
   <oslc:shortTitle>REQ-020188-A</oslc:shortTitle>
   <dcterms:isVersionOf rdf:resource="http://localhost:8082/rio-rm/requirement/46"/>
   <applicationRef xmlns="http://www.plmxml.org/Schemas/PLMXMLSchema#">
      <ApplicationRef xmlns="http://www.plmxml.org/Schemas/PLMXMLSchema#" rdf:nodeID="node163c1ee6kx1">
         <version xmlns="http://www.plmxml.org/Schemas/PLMXMLSchema#">2.0</version>
         <application xmlns="http://www.plmxml.org/Schemas/PLMXMLSchema#">TOPCASED_XMI</application>
         <label xmlns="http://www.plmxml.org/Schemas/PLMXMLSchema#">_bqSmIGIeEeCPfc4lo-UQrg</label>
      </ApplicationRef>
   </applicationRef>
</oslc_rm:Requirement>

</rdf:RDF>
 

• Validate RDF: req_46.xml

<rdf:RDF
   xmlns:oslc_rm="http://open-services.net/ns/rm#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:oslc="http://open-services.net/ns/core#"
   xmlns:dcterms="http://purl.org/dc/terms/"
   xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">
<oslc_rm:Requirement rdf:about="http://localhost:8082/rio-rm/requirement/46">
   <rdf:type rdf:resource="http://open-services.net/ns/am#Resource"/>
   <dcterms:title>EU MarketRegion</dcterms:title>
   <dcterms:identifier>46</dcterms:identifier>
   <dcterms:modified rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2011-07-21T09:18:35.858-04:00</dcterms:modified>
   <dcterms:created rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2011-06-28T17:10:51.347-04:00</dcterms:created>
   <dcterms:creator rdf:resource="http://localhost:8082/rio-rm/user/_UNKNOWN_USER_"/>
   <dcterms:contributor rdf:resource="http://localhost:8082/rio-rm/user/_UNKNOWN_USER_"/>
   <oslc:shortTitle>REQ-020188</oslc:shortTitle>
   <applicationRef xmlns="http://www.plmxml.org/Schemas/PLMXMLSchema#" rdf:nodeID="node1656di0nlx1"/>
   <dcterms:hasVersion rdf:resource="http://localhost:8082/rio-rm/requirement/45"/>
   <dcterms:hasVersion rdf:resource="http://localhost:8082/rio-rm/requirement/49"/>
</oslc_rm:Requirement>
<ApplicationRef xmlns="http://www.plmxml.org/Schemas/PLMXMLSchema#" rdf:nodeID="node1656di0nlx1">
   <version xmlns="http://www.plmxml.org/Schemas/PLMXMLSchema#">2.0</version>
   <application xmlns="http://www.plmxml.org/Schemas/PLMXMLSchema#">TOPCASED_XMI</application>
   <label xmlns="http://www.plmxml.org/Schemas/PLMXMLSchema#">REQ-020188</label>
</ApplicationRef>

</rdf:RDF>
 

To capture the ordering of the versions, a "replaces" link MUST be used to explicitly record the starting point of any new version as it is created. This new version is still a "versionOf" the base, but it also points to the previous version. Note that this approach can support branching, since any number of "replaces" links can point back to a single "branch point" version. Note that the choice of the word "replaces" is a bit misleading, since any of the versions may be actively in use in a given product at any given effective point; "replaces" purely denotes the relationship between a prior version and a next version in the version progression (carrying the same information as the "preceding" part of the "preceding/following" relation entity in STEP).

• Validate RDF: req_49.xml

<rdf:RDF
   xmlns:oslc_rm="http://open-services.net/ns/rm#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:oslc="http://open-services.net/ns/core#"
   xmlns:dcterms="http://purl.org/dc/terms/"
   xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">
<oslc_rm:Requirement rdf:about="http://localhost:8082/rio-rm/requirement/49">
   <rdf:type rdf:resource="http://open-services.net/ns/am#Resource"/>
   <dcterms:title>EU MarketRegion as of 2011</dcterms:title>
   <dcterms:description>The product shall be marketable in the European Union (EU) geopolitical region, as it exists in 2011.</dcterms:description>
   <dcterms:identifier>49</dcterms:identifier>
   <dcterms:modified rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2011-07-21T08:54:50.625-04:00</dcterms:modified>
   <dcterms:created rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2011-07-21T08:54:50.625-04:00</dcterms:created>
   <dcterms:creator rdf:resource="http://localhost:8082/rio-rm/user/_UNKNOWN_USER_"/>
   <dcterms:contributor rdf:resource="http://localhost:8082/rio-rm/user/_UNKNOWN_USER_"/>
   <oslc:shortTitle>REQ-020188-B</oslc:shortTitle>
   <dcterms:isVersionOf rdf:resource="http://localhost:8082/rio-rm/requirement/46"/>
   <applicationRef xmlns="http://www.plmxml.org/Schemas/PLMXMLSchema#" rdf:nodeID="node1656c6guex1"/>
   <dcterms:replaces rdf:resource="http://localhost:8082/rio-rm/requirement/45"/>
</oslc_rm:Requirement>
<ApplicationRef xmlns="http://www.plmxml.org/Schemas/PLMXMLSchema#" rdf:nodeID="node1656c6guex1">
   <version xmlns="http://www.plmxml.org/Schemas/PLMXMLSchema#">2.0</version>
   <application xmlns="http://www.plmxml.org/Schemas/PLMXMLSchema#">TOPCASED_XMI</application>
   <label xmlns="http://www.plmxml.org/Schemas/PLMXMLSchema#">_bqSmIGIeEeCPfc4lo-XXXX</label>
</ApplicationRef>

</rdf:RDF>
 

Resource View Definition (a.k.a. Resource Context or Product View Definition) Proposal

This is a proposed approach to defining the OSLC resource needed to capture the concept described STEP as the Product View Definition. This completes the key three part structure that is used throughout the STEP and PLM models - Product->Product Version->Product View Definition. This proposal also includes provisions for adding Variant Expressions to the links, thus enabling Option and Variant Effectivity to be established in the view.

Key Considerations

Some key considerations that have shaped this proposal:

• URI encoding should be avoided; all relationships must be explicitly represented by a link
• Use core concepts already defined by Web standards if they exist
• Frame the proposal in a way that it will fit into the OSLC Core specification, thus applying to all domain specifications in the same way.
• Make the proposed approach compatible with PLM concepts, and compatible with the proposed approach for Version Progression Linking.
• Make the proposed approach compatible with the proposed approach for Variant Expressions.
• Make the proposed approach useful for baselining.

The general approach to representing the Product View Definition is very similar to the STEP model. A separate resource is proposed (in general a <Resource>View, i.e. RequirementView? ) that serves the sole purpose of linking the resources that compose the view to the top level resource (version) that the view represents. A simple example of this is a two level structure of Requirement, one Requirement at the top level and a set of Requirements at the next level that are all constituents of the top level. This structure is built in SysML? by using the NestedClassifier? relationship (see the SysML? standards for details).

In the STEP model, the constituent relationships are all made between the view of the top level resource and the like classified view of the constituent resources. This approach allows for multiple different views, each of a different type, which can describe very different composition relationships. For example, the composition structure of a device as described in the electronic circuit domain (sometimes referred to as "discipline") can be quite different from the composition structure of that same device as described in the mechanical assembly domain, or the software source code domain. A multi-layered, multi-view modeling approach lets all of these discipline specific views of the identical device coexist and be synchronized.

Another major consideration is the way of handling referential integrity in the links to constituent resources. In general, no referential integrity is implied or required by the RDF; a URI in a link is not guaranteed to point to any real resource at any time. Providers themselves are not so forgiving, and many will not be able to handle this referential issue at all. This proposal includes some OSLC Core Specification text to explain the preferred and mandatory aspects of handling the referential issue.

Text to be Added to the OSLC Core Specification

Text to be Added to the OSLC Requirements Management Specification (this example could be adapted to apply in any domain specification)

RDF Examples

This set of examples shows a complete set of resources to represent the Requirement->Requirement Version->Requirement View Definition structure of a top level requirement from the Hybrid SUV example used in the SysML? Specification. The approach used here introduces a new OSLC RM resource Named RequirementView? , which has a small set of mandatory properties (in addition to the normal Core properties for ownership, modification date, etc.). This resource is the linking point for all structural usages, and the links contained here include Anchors for variant expressions and other "instantiaion" properties to be added. The view example shows how a variant expression would look in this approach. The view points to the sub-requirements it is composed of by use of the dcterms:hasPart property. It is important to note that the converse property (isPartOf) MAY be used on the sub-requirement. OWL based reasoners can infer that relationship...

First, the top level "base" requirement resource:

• Validate RDF: req_63.xml

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:oslc="http://open-services.net/ns/core#" xmlns:oslc_rm="http://open-services.net/ns/rm#" xmlns:pr0="http://www.plmxml.org/Schemas/PLMXMLSchema#" xmlns:rio="http://open-services.net/ri/" xml:base="http://localhost:8082/rio-rm/requirement/63">
  <oslc_rm:Requirement rdf:about="http://localhost:8082/rio-rm/requirement/63">
    <rdf:type rdf:resource="http://open-services.net/ns/rm#Requirement"/>
    <dcterms:title>MarketRegion</dcterms:title>
    <dcterms:identifier>63</dcterms:identifier>
    <dcterms:modified rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2011-07-27T14:27:24.243-04:00</dcterms:modified>
    <dcterms:created rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2011-07-27T14:27:12.866-04:00</dcterms:created>
    <dcterms:creator rdf:resource="http://localhost:8082/rio-rm/user/_UNKNOWN_USER_"/>
    <dcterms:contributor rdf:resource="http://localhost:8082/rio-rm/user/_UNKNOWN_USER_"/>
    <oslc:shortTitle>REQ-020186</oslc:shortTitle>
    <pr0:applicationRef>
      <pr0:ApplicationRef>
        <pr0:version>2.0</pr0:version>
        <pr0:application>TOPCASED_XMI</pr0:application>
        <pr0:label>REQ-020186</pr0:label>
      </pr0:ApplicationRef>
    </pr0:applicationRef>
    <dcterms:hasVersion rdf:resource="http://localhost:8082/rio-rm/requirement/62"/>
  </oslc_rm:Requirement>
</rdf:RDF>

Next, the requirement version resource:

Validate RDF: req_62.xml

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:oslc="http://open-services.net/ns/core#" xmlns:oslc_rm="http://open-services.net/ns/rm#" xmlns:pr0="http://www.plmxml.org/Schemas/PLMXMLSchema#" xmlns:pr1="http://www.omg.org/spec/SysML/20100301/UML4SysML#" xmlns:rio="http://open-services.net/ri/" xml:base="http://localhost:8082/rio-rm/requirement/62">
  <oslc_rm:Requirement rdf:about="http://localhost:8082/rio-rm/requirement/62">
    <rdf:type rdf:resource="http://open-services.net/ns/rm#Requirement"/>
    <rdf:type rdf:resource="http://open-services.net/ns/rm#RequirementVersion"/>
    <dcterms:title>MarketRegion</dcterms:title>
    <dcterms:description>The product
         shall be marketable in one or more distinct geopolitical regions.</dcterms:description>
    <dcterms:identifier>62</dcterms:identifier>
    <dcterms:modified rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2011-07-27T14:27:24.069-04:00</dcterms:modified>
    <dcterms:created rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2011-07-27T14:27:12.757-04:00</dcterms:created>
    <dcterms:creator rdf:resource="http://localhost:8082/rio-rm/user/_UNKNOWN_USER_"/>
    <dcterms:contributor rdf:resource="http://localhost:8082/rio-rm/user/_UNKNOWN_USER_"/>
    <oslc:shortTitle>REQ-020186-A</oslc:shortTitle>
    <dcterms:isVersionOf rdf:resource="http://localhost:8082/rio-rm/requirement/63"/>
    <pr0:applicationRef>
      <pr0:ApplicationRef>
        <pr0:version>2.0</pr0:version>
        <pr0:application>TOPCASED_XMI</pr0:application>
        <pr0:label>Rev__2wRcUGIbEeCPfc4lo-UQrg</pr0:label>
      </pr0:ApplicationRef>
    </pr0:applicationRef>
    <pr1:nestedClassifier rdf:resource="http://localhost:8082/rio-rm/requirement/61"/>
  </oslc_rm:Requirement>
</rdf:RDF>

Third, the requirement view resource:

Validate RDF: req_61.xml

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:oslc="http://open-services.net/ns/core#" xmlns:oslc_rm="http://open-services.net/ns/rm#" xmlns:pr0="http://www.plmxml.org/Schemas/PLMXMLSchema#" xmlns:rio="http://open-services.net/ri/" xml:base="http://localhost:8082/rio-rm/requirement/61">
  <oslc_rm:Requirement rdf:about="http://localhost:8082/rio-rm/requirement/61">
    <rdf:type rdf:resource="http://open-services.net/ns/rm#Requirement"/>
    <rdf:type rdf:resource="http://open-services.net/ns/rm#RequirementView"/>
    <dcterms:title>MarketRegion View</dcterms:title>
    <dcterms:identifier>61</dcterms:identifier>
    <dcterms:modified rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2011-07-27T14:27:23.782-04:00</dcterms:modified>
    <dcterms:created rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2011-07-27T14:27:12.654-04:00</dcterms:created>
    <dcterms:creator rdf:resource="http://localhost:8082/rio-rm/user/_UNKNOWN_USER_"/>
    <dcterms:contributor rdf:resource="http://localhost:8082/rio-rm/user/_UNKNOWN_USER_"/>
    <oslc:shortTitle>REQ-020186-A_view</oslc:shortTitle>
    <pr0:applicationRef>
      <pr0:ApplicationRef>
        <pr0:version>2.0</pr0:version>
        <pr0:application>TOPCASED_XMI</pr0:application>
        <pr0:label>View__2wRcUGIbEeCPfc4lo-UQrg</pr0:label>
      </pr0:ApplicationRef>
    </pr0:applicationRef>
    <dcterms:subject rdf:resource="http://localhost:8082/rio-rm/requirement/62"/>
    <dcterms:hasPart rdf:ID="Part__J1yCsGIeEeCPfc4lo-UQrg" rdf:resource="http://localhost:8082/rio-rm/requirement/64"/>
    <dcterms:hasPart rdf:ID="Part__bqSmIGIeEeCPfc4lo-UQrg" rdf:resource="http://localhost:8082/rio-rm/requirement/67"/>
  </oslc_rm:Requirement>
  <rdf:Description rdf:about="#Part__J1yCsGIeEeCPfc4lo-UQrg">
    <pr0:VariantExpression>MarketRegion=US</pr0:VariantExpression>
  </rdf:Description>
  <rdf:Description rdf:about="#Part__bqSmIGIeEeCPfc4lo-UQrg">
    <pr0:VariantExpression>MarketRegion=EU</pr0:VariantExpression>
  </rdf:Description>
</rdf:RDF>

Finally, the similar three part example of one of the sub-requirements being pointed to:

Validate RDF: req_66.xml

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:oslc="http://open-services.net/ns/core#" xmlns:oslc_rm="http://open-services.net/ns/rm#" xmlns:pr0="http://www.plmxml.org/Schemas/PLMXMLSchema#" xmlns:rio="http://open-services.net/ri/" xml:base="http://localhost:8082/rio-rm/requirement/66">
  <oslc_rm:Requirement rdf:about="http://localhost:8082/rio-rm/requirement/66">
    <rdf:type rdf:resource="http://open-services.net/ns/rm#Requirement"/>
    <dcterms:title>US MarketRegion</dcterms:title>
    <dcterms:identifier>66</dcterms:identifier>
    <dcterms:modified rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2011-07-27T14:27:24.695-04:00</dcterms:modified>
    <dcterms:created rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2011-07-27T14:27:13.186-04:00</dcterms:created>
    <dcterms:creator rdf:resource="http://localhost:8082/rio-rm/user/_UNKNOWN_USER_"/>
    <dcterms:contributor rdf:resource="http://localhost:8082/rio-rm/user/_UNKNOWN_USER_"/>
    <oslc:shortTitle>REQ-020187</oslc:shortTitle>
    <pr0:applicationRef>
      <pr0:ApplicationRef>
        <pr0:version>2.0</pr0:version>
        <pr0:application>TOPCASED_XMI</pr0:application>
        <pr0:label>REQ-020187</pr0:label>
      </pr0:ApplicationRef>
    </pr0:applicationRef>
    <dcterms:hasVersion rdf:resource="http://localhost:8082/rio-rm/requirement/65"/>
  </oslc_rm:Requirement>
</rdf:RDF>

Validate RDF: req_65.xml

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:oslc="http://open-services.net/ns/core#" xmlns:oslc_rm="http://open-services.net/ns/rm#" xmlns:pr0="http://www.plmxml.org/Schemas/PLMXMLSchema#" xmlns:pr1="http://www.omg.org/spec/SysML/20100301/UML4SysML#" xmlns:rio="http://open-services.net/ri/" xml:base="http://localhost:8082/rio-rm/requirement/65">
  <oslc_rm:Requirement rdf:about="http://localhost:8082/rio-rm/requirement/65">
    <rdf:type rdf:resource="http://open-services.net/ns/rm#Requirement"/>
    <rdf:type rdf:resource="http://open-services.net/ns/rm#RequirementVersion"/>
    <dcterms:title>US MarketRegion</dcterms:title>
    <dcterms:description>The product
         shall be marketable in the United States (US) geopolitical region.</dcterms:description>
    <dcterms:identifier>65</dcterms:identifier>
    <dcterms:modified rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2011-07-27T14:27:24.539-04:00</dcterms:modified>
    <dcterms:created rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2011-07-27T14:27:13.077-04:00</dcterms:created>
    <dcterms:creator rdf:resource="http://localhost:8082/rio-rm/user/_UNKNOWN_USER_"/>
    <dcterms:contributor rdf:resource="http://localhost:8082/rio-rm/user/_UNKNOWN_USER_"/>
    <oslc:shortTitle>REQ-020187-A</oslc:shortTitle>
    <dcterms:isVersionOf rdf:resource="http://localhost:8082/rio-rm/requirement/66"/>
    <pr0:applicationRef>
      <pr0:ApplicationRef>
        <pr0:version>2.0</pr0:version>
        <pr0:application>TOPCASED_XMI</pr0:application>
        <pr0:label>Rev__J1yCsGIeEeCPfc4lo-UQrg</pr0:label>
      </pr0:ApplicationRef>
    </pr0:applicationRef>
    <pr1:nestedClassifier rdf:resource="http://localhost:8082/rio-rm/requirement/64"/>
  </oslc_rm:Requirement>
</rdf:RDF>

Validate RDF: req_64.xml

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:oslc="http://open-services.net/ns/core#" xmlns:oslc_rm="http://open-services.net/ns/rm#" xmlns:pr0="http://www.plmxml.org/Schemas/PLMXMLSchema#" xmlns:rio="http://open-services.net/ri/" xml:base="http://localhost:8082/rio-rm/requirement/64">
  <oslc_rm:Requirement rdf:about="http://localhost:8082/rio-rm/requirement/64">
    <rdf:type rdf:resource="http://open-services.net/ns/rm#Requirement"/>
    <rdf:type rdf:resource="http://open-services.net/ns/rm#RequirementView"/>
    <dcterms:title>US MarketRegion View</dcterms:title>
    <dcterms:identifier>64</dcterms:identifier>
    <dcterms:modified rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2011-07-27T14:27:24.387-04:00</dcterms:modified>
    <dcterms:created rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2011-07-27T14:27:12.973-04:00</dcterms:created>
    <dcterms:creator rdf:resource="http://localhost:8082/rio-rm/user/_UNKNOWN_USER_"/>
    <dcterms:contributor rdf:resource="http://localhost:8082/rio-rm/user/_UNKNOWN_USER_"/>
    <oslc:shortTitle>REQ-020187-A_view</oslc:shortTitle>
    <pr0:applicationRef>
      <pr0:ApplicationRef>
        <pr0:version>2.0</pr0:version>
        <pr0:application>TOPCASED_XMI</pr0:application>
        <pr0:label>View__J1yCsGIeEeCPfc4lo-UQrg</pr0:label>
      </pr0:ApplicationRef>
    </pr0:applicationRef>
    <dcterms:subject rdf:resource="http://localhost:8082/rio-rm/requirement/65"/>
  </oslc_rm:Requirement>
</rdf:RDF>

Application Reference (AppRef? ) Proposal

This is a proposed approach to standardize added resource properties to carry application specific identifier information. This identifier information would typically be managed by applications that are not capable of using URI's as resource identifiers. By supporting these application specific identifiers in all OSLC providers, the identities of the resources can be preserved across multiple provider/consumer pairings.

Variant Expression Proposal

This is a proposed approach to representing variant expressions as resource properties. These properties will be used by ALM and/or PLM systems to select the appropriate resources for a given product option configuration. In concert with date, lot and version effectivity, these variant conditions let the resource set exactly represent any given product configuration at any effective point in the lifecycle.

Key Considerations

Some key considerations that have shaped this proposal:

• Use core concepts already defined by Web standards if they exist.
• Frame the proposal in a way that it will fit into the OSLC Core specification, thus applying to all domain specifications in the same way.
• Make the proposed approach compatible with PLM concepts, and compatible with the proposed approach for Version Progression Linking.
• Make the proposed approach compatible with the proposed approach for Resource View Definitions.
• Make the proposed approach compatible with baselining.

The general approach is to use Anchor properties attached to the view constituent links within the Resource View Definition. The properties to use to represent the Variant Expression are standardized so that the syntax and semantics of the expression can be interpreted in a common way across all OSLC domain specifications. General boolean expressions are supported including grouping to support arbitrary order of evaluation. The operator syntax matches SPARQL to make conversion of the variant expressions to SPARQL queries (one possible implementation approach to generating a variant-effective view) more convenient.

Text to be Added to the OSLC Core Specification

RDF Examples

-- MikeLoeffler - 18 Jul 2011