Plm20SpecExtensions < Main

This wiki is locked. Future workgroup activity and specification development must take place at our new wiki. For more information, see this blog post about the new governance model and this post about changes to the website.
TWiki>
Main Web>PlmHome>Plm20SpecExtensions (06 Jan 2012, GrayBachelor) (raw view)
-- Main.GrayBachelor - 10 Aug 2011
---+++ Proposal for OSLC Product Management PM Spec 2.0 extensions to support PLM behavior
---+ Draft for feedback(Note this page is superceded and being harvested)

You can find the new draft here as the [[PlmSpecExtensions][PLM Spec Extensions]]
---++ 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-&gt;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:

<blockquote><literal><pre>A <strong>Product_version</strong> is  a revision of a <strong>Product</strong>. It is a collector of the definitions of this revision of the <strong>Product</strong>. </pre></literal><pre><a name="note_" title="note_"></a>NOTE  The set of all instances of *Product_version* of the same *Product* represents the history of the product.  </pre></blockquote>

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. %RED%Scenarios to illustrate some mappings for popular providers should be developed. %ENDCOLOR%
---+++ 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
<literal>dcterms:hasVersion</literal> 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.

   * [[http://www.w3.org/RDF/Validator/ARPServlet?URI=%ATTACHURL%/req_45.xml&PARSE=Parse+URI%3A+&TRIPLES_AND_GRAPH=PRINT_TRIPLES][Validate RDF]]: req_45.xml
<blockquote><verbatim><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>
 </verbatim></blockquote>

   * [[http://www.w3.org/RDF/Validator/ARPServlet?URI=%ATTACHURL%/req_46.xml&PARSE=Parse+URI%3A+&TRIPLES_AND_GRAPH=PRINT_TRIPLES][Validate RDF]]: req_46.xml
<blockquote><verbatim><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>
 </verbatim></blockquote>

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).

   * [[http://www.w3.org/RDF/Validator/ARPServlet?URI=%ATTACHURL%/req_49.xml&PARSE=Parse+URI%3A+&TRIPLES_AND_GRAPH=PRINT_TRIPLES][Validate RDF]]: req_49.xml
<blockquote><verbatim><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>
 </verbatim></blockquote>

---++ 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-&gt;Product Version-&gt;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 &lt;Resource&gt;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-&gt;Requirement Version-&gt;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 <literal>dcterms:hasPart</literal> property. It is important to note that the converse property (<literal>isPartOf</literal>) *MAY* be used on the sub-requirement. %RED%OWL based reasoners can infer that relationship...%ENDCOLOR%

First, the top level "base" requirement resource:

   * [[http://www.w3.org/RDF/Validator/ARPServlet?URI=%ATTACHURL%/req_63.xml&PARSE=Parse+URI%3A+&TRIPLES_AND_GRAPH=PRINT_TRIPLES][Validate RDF]]: req_63.xml
<blockquote><verbatim>
<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>
</verbatim></blockquote>

Next, the requirement version resource:

[[http://www.w3.org/RDF/Validator/ARPServlet?URI=%ATTACHURL%/req_62.xml&PARSE=Parse+URI%3A+&TRIPLES_AND_GRAPH=PRINT_TRIPLES][Validate RDF]]: req_62.xml
<blockquote><verbatim><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>
</verbatim></blockquote>

Third, the requirement view resource:

[[http://www.w3.org/RDF/Validator/ARPServlet?URI=%ATTACHURL%/req_61.xml&PARSE=Parse+URI%3A+&TRIPLES_AND_GRAPH=PRINT_TRIPLES][Validate RDF]]: req_61.xml
<blockquote><verbatim><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>
</verbatim></blockquote>

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

[[http://www.w3.org/RDF/Validator/ARPServlet?URI=%ATTACHURL%/req_66.xml&PARSE=Parse+URI%3A+&TRIPLES_AND_GRAPH=PRINT_TRIPLES][Validate RDF]]: req_66.xml
<blockquote><verbatim><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>
</verbatim></blockquote>

[[http://www.w3.org/RDF/Validator/ARPServlet?URI=%ATTACHURL%/req_65.xml&PARSE=Parse+URI%3A+&TRIPLES_AND_GRAPH=PRINT_TRIPLES][Validate RDF]]: req_65.xml
<blockquote><verbatim><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>
</verbatim></blockquote>

[[http://www.w3.org/RDF/Validator/ARPServlet?URI=%ATTACHURL%/req_64.xml&PARSE=Parse+URI%3A+&TRIPLES_AND_GRAPH=PRINT_TRIPLES][Validate RDF]]: req_64.xml
<blockquote><verbatim><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>
</verbatim></blockquote>

#AppRef
---++ 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

-- Main.MikeLoeffler - 18 Jul 2011
Attachments
Topic attachments
I	Attachment	Action	Size	Date	Who
xml	req_45.xml	manage	1.7 K	18 Jul 2011 - 20:47	MikeLoeffler
xml	req_46.xml	manage	1.6 K	18 Jul 2011 - 20:48	MikeLoeffler
xml	req_49.xml	manage	1.8 K	21 Jul 2011 - 13:44	MikeLoeffler
xml	req_61.xml	manage	2.1 K	27 Jul 2011 - 19:25	MikeLoeffler
xml	req_62.xml	manage	1.9 K	27 Jul 2011 - 19:28	MikeLoeffler
xml	req_63.xml	manage	1.5 K	27 Jul 2011 - 19:30	MikeLoeffler
xml	req_64.xml	manage	1.6 K	27 Jul 2011 - 19:35	MikeLoeffler
xml	req_65.xml	manage	1.9 K	27 Jul 2011 - 19:37	MikeLoeffler
xml	req_66.xml	manage	1.5 K	27 Jul 2011 - 19:38	MikeLoeffler
Topic revision: r8 - 06 Jan 2012 - 20:32:06 - GrayBachelor
Main
Webs
Main
Sandbox
TWiki
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use
Ideas, requests, problems regarding this site? Send feedback