Added inverse function properties #190. Fixed xml narrative.

model/config.js

@@ -1,7 +1,7 @@
 var respecConfig = {
         specStatus: "ED",
         shortName:  "odrl-model",
-        publishDate:          "2017-06-14",
+        publishDate:          "2017-06-15",
         editors: [
             {   name:       "Renato Iannella",
                     url:        "https://au.linkedin.com/in/riannella",

model/index.html

@@ -329,21 +329,23 @@ <h4>Relation</h4>
 </section>
 
        <section id="policy-has">
-<h3>Has A Policy</h3> 
-<p>The Policy class MAY also be referenced by the <code>hasPolicy</code> property. This supports ODRL Policy Rules being the object of external metadata expressions (that describe an Asset). When <code>hasPolicy</code> has been asserted between a metadata expression and an ODRL Policy, the Asset being identified MUST be inferred to be the target Asset of all the Rules of the Policy. If there are multiple Rules in the Policy, then the inferred Asset will be the target Asset to each Rule.</p>
+<h3>Target Policy</h3> 
+
+<p>An ODRL Policy class MAY also be referenced by the <code>hasPolicy</code> property. This supports ODRL Policy Rules being the object of external metadata expressions (that identifies an Asset). When <code>hasPolicy</code> has been asserted between a metadata expression and an ODRL Policy, the Asset being identified MUST be inferred to be the <code>target</code> Asset of all the Rules of that Policy. If there are multiple Rules in the Policy, then the inferred Asset will be the target Asset to <strong>every</strong> Rule in the Policy. (Note: The <code>hasPolicy</code> property can be considered to be the inverse of the <code>target</code> property.)</p>
 
 <blockquote>
-<p>Example Use Case: The below snippet shows some Dublin Core metadata describing a movie Asset. The <code>odrl:hasPolicy</code> property has been included to link to the ODRL Policy <code>http://example.com/policy:1010</code> (this is the Set Policy described above). In this case, the Asset <code>http://example.com/asset:9999.movie</code> is now also the target Asset for the Permission in Policy <code>http://example.com/policy:1010</code>. If there were additional Rules in this Policy, then the same target Asset would apply.</p>
+<p>Example Use Case: The below snippet shows some Dublin Core metadata describing a movie Asset. The <code>odrl:hasPolicy</code> property has been included to link to the ODRL Policy <code>http://example.com/policy:1010</code> (this is the Set Policy described above). In this case, the Asset <code>http://example.com/asset:9999.movie</code> is now also the target Asset for the Permission in Policy <code>http://example.com/policy:1010</code>. If there were additional Rules in this Policy, then the same Asset would be the target Asset to each Rule.</p>
 </blockquote>
 
 <pre class="example hljs json">
 {
-   ...
+   "@type": "dc:MovingImage",
+   "@id": "http://example.com/asset:9999.movie",
    "dc:publisher": "ABC Pictures",
    "dc:creator": "Allen, Woody",
    "dc:issued": "2017",
    "dc:subject": "Musical Comedy",
-   "dc:identifier": "http://example.com/asset:9999.movie",
+   ...
    "odrl:hasPolicy": "http://example.com/policy:1010",
    ...
 }
@@ -445,11 +447,37 @@ <h4>Function</h4>
     }]
 }  
 </pre>
-    
+
 
 </section>
 
+<section id="policy-assigned">
+<h3>Assigned Policy</h3> 
+
+<p>An ODRL Policy class MAY also be referenced by the <code>assignerOf</code> and  <code>assigneeOf</code> properties. This supports ODRL Policy Rules being the object of external metadata expressions (that identifies a Party). When <code>assignerOf</code> has been asserted between a metadata expression and an ODRL Policy, the Party being identified MUST be inferred to undertake the <code>assigner</code> functional role of all the Rules of that Policy. When <code>assigneeOf</code> has been asserted between a metadata expression and an ODRL Policy, the Party being identified MUST be inferred to undertake the <code>assignee</code> functional role of all the Rules of that Policy.
+
+	If there are multiple Rules in the Policy, then the inferred Party will undertake the functional role  to <strong>every</strong> Rule in the Policy. (Note: The <code>assignerOf</code> and <code>assigneeOf</code> properties can be considered to be the inverse of the <code>assigner</code> and <code>assignee</code> properties, respectively.)</p>
+
+<blockquote>
+<p>Example Use Case: The below snippet shows some vCard metadata describing an individual Party. The <code>odrl:assigneeOf</code> property has been included to link to the ODRL Policy <code>http://example.com/policy:1011</code> (this is the Offer Policy described above). In this case, the Party <code>http://example.com/person/billie</code> is now also the assignee of the Permission in Policy <code>http://example.com/policy:1011</code>. If there were additional Rules in this Policy, then the same Party would the assignee for each Rule.</p>
+</blockquote>
 
+<pre class="example hljs json">
+{
+   "@type": "vcard:Individual",
+   "@id": "http://example.com/person/billie",
+   "vcard:fn": "Billie",
+   "vcard:hasEmail": "billie@example.com",
+   ...
+   "odrl:assigneeOf": "http://example.com/policy:1010",
+   ...
+}
+</pre>
+
+    </section>
+
+
+
 
     </section>
 
@@ -1507,6 +1535,9 @@ <h3>Changes from Previous Versions</h3>
     <li>Added hasPolicy property <a href="https://github.com/w3c/poe/issues/184">(Issue#184)</a></li>
 
      <li>Added includedIn and implies properties for Action. Added partOf property for Asset and Party <a href="https://github.com/w3c/poe/issues/160">(Issue#160)</a></li>
+
+	<li>Added assignerOf/assigneeOf inverse properties <a href="https://github.com/w3c/poe/issues/190">(Issue#190)</a></li>
+
 
 </ul>
 </section>

vocab/config.js

@@ -1,7 +1,7 @@
 var respecConfig = {
     specStatus: "ED",
     shortName: "odrl-vocab",
-    publishDate:  "2017-06-13",
+    publishDate:  "2017-06-15",
     edDraftURI: "https://w3c.github.io/poe/vocab/",
     editors: [
         {    name:       "Renato Iannella",

vocab/parts/xml.html

@@ -204,10 +204,10 @@ <h2>XML Linking</h2>
 </section>
 
 <section>
-<h2>Constraint Relations</h2>
-<p>To support Constraint Relations, constraint objects can be expressed at the Policy level and locally identified with the <code>id</code> attribute. The constraint (in the Permission, Prohibition, or Duty) can then refer to these constraints using its <code>#id</code>.</p>
- <p>ODRL XML processing systems MUST detect the use of <code>#id</code> in the name attribute and rightOperand in Constraints. If detected, the processing model for Constraint Relations (defined in [[!odrl-model]]) MUST then be followed.</p>
-<p>The below example shows two constraints defined at the Policy-level with ids <code>C1</code> and <code>C2</code>. The Constraint in the permission refers to these using the <code>#C1</code> and <code>#C2</code> values.</p>   
+<h2>Compound Constraints</h2>
+<p>To support Compound Constraints, Atomic Constraint objects can be expressed at the Policy level and locally identified with the <code>id</code> attribute. The Compound Constraint (in the Rule) can then refer to these Atomic Constraints using its <code>#id</code>.</p>
+ <p>ODRL XML processing systems MUST detect the use of <code>#id</code> in the name attribute and rightOperand in Compound Constraints. If detected, the processing model for Compound Constraints (defined in [[!odrl-model]]) MUST then be followed.</p>
+<p>The below example shows two Atomic Constraints defined at the Policy-level with ids <code>C1</code> and <code>C2</code>. The Compound Constraint in the Permission refers to these using the <code>#C1</code> and <code>#C2</code> values.</p>   
 
 <pre class="example  xml">
 &lt;o:Policy xmlns:o="http://www.w3.org/ns/odrl/2/" uid="http://example.com/policy:9001"