Some comments on the model

As you may have just seen, I've been reading through the model doc 
again, this time looking for validation/processing rules. In doing so, I 
have made some notes. Some of these might end up as separate issues but 
the majority are editorial.

3.2.1 Relation.

I am confused by the section being about the relation property and then 
the example uses target. Suggest: use text from the vocab doc to explain 
that relation is an abstract property with two sub properties, target 
and output that are the ones expected to be used. Even the Note doesn't 
fully explain this.

===

Example 5 uses a property of x:collection. It is more normal to use the 
prefix 'ex' rather than 'x'.

===

Section 3.2 says that an Asset MAY have a scope. Section 3.2.2 says it 
SHOULD. Suggest one of these needs updating.

===

Typo in section 3.2.2

"The scope feature is useful is there is no ability ..."

Should be

"The scope feature is useful if there is no ability ..."  (if not is)

===

Section 3.2.2 contains this paragraph:

"Example Use Case: The Policy defines a target Asset 
http://example.com/media-catalogue that is a collection of multimedia 
files. The target Asset also has a scope of http://example.com/imt/jpeg. 
That scope specifies further context on what characteristics the Asset 
items must hold - in this case, the target Asset(s) will be all the 
files identified by the taget uid that are of type "jpeg"."

I don't see how one can infer the conclusion that the target Assets are 
of the type jpeg.

http://example.com/imt/jpeg is a URI and is therefore a dumb string with 
no semantics, so it is incorrect to infer any info just from that.

Is the case that I should dereference that URI to find out that it only 
applies to JPEGs? I can imagine that the scope property might be defined 
to take a MIME type, but would that cover all cases for scope?

===

I note several references to ODRL Profiles, a section that may be about 
to be removed.

===

3.3.1 Function
As above, I find it confusing that the function property is not used in 
the example, rather, its sub properties. Again, it would help me if the 
sub properties of function were spelled out in section 3.3.1. Suggest 
slight alteration to the text as follows:

A function property is used to link a Rule to a Party, indicating the 
function undertaken by the Party in respect to the Rule that links to 
it. The function property itself is abstract; subproperties represent 
explicit semantics of the functional role between the Party and the Rule.

The most important sub properties of function are:

*Or*

An ODRL processor MUST recognize the following sub properties:

===

3.3.2

The copy and paste from Asset has included the is/if typo

===

3.3.2

Suggest that "The scope property may be one of the following:" should be

"The value of the scope property may be..."

===

3.3.2

Suggest that "Other scope property IRI values should be defined in the 
ODRL Vocabulary [vocab-odrl] and ODRL Profiles." should be:

Other scope property IRI values are be defined in the ODRL Vocabulary 
[vocab-odrl] and ODRL Profiles.  (should/are)


===

3.3.2

Grammar police:

Example Use Case: The target Asset http://example.com/myPhotos:BdayParty 
are a set of photos

Should be

Example Use Case: The target Asset http://example.com/myPhotos:BdayParty 
is a set of photos  (are/is)

===

3.2.2

As before, how is this true? "the scope of the Assignee has been also be 
declared as http://example.com/people/age/18+ "

What is/needs to be returned from http://example.com/people/age/18+ for 
a processor to understand the scope?

===

3.4

Suggest

"An Action indicates an operation that can be applied to an Asset. An 
Action is associated to the Asset with the action property in a Rule."

would be better worded as

An Action indicates an operation that can be applied to an Asset. An 
Action is associated with the Asset via the action property in a Rule. 
(to/with; with/via)

=== 3.5==

Picking up on earlier comments, I suggest slight additions to these bullets:


A Rule may have an Asset via a sub property of the relation property
A Rule may have one or more Parties via a sub property of the function 
property


And then I'd reword "The abstract relation and function properties must 
be represented as explicit types of these properties in the subclasses 
of a Rule." as

Explicit sub properties of the abstract relation and function properties 
must be used, the choice depending on the subclass of Rule in question.

===

3.5.1

The word 'may' in this sentence is shown with RFC2119 semantics - which 
I don't think is correct or intended in this context. "A Permission 
class is a subclass of Rule that specifies the Actions that may be 
performed on an Asset. The Permission class inherits all the properties 
from the Rule class."

===
3.5.1

"In addition to the Rule properties, the Permission class has the 
following:" should be appended to read

In addition to the Rule properties, the Permission class has the 
following characteristics:

===
3.5.1

I find this confusing: "A Permission must have an Asset via the target 
relation property. Other types of relation properties for Asset may be 
used."

I *think* this means:

A Permission must be linked to an Asset via a target property. This does 
not restrict the sub property of <code>relation</code> that are used as 
properties of the Asset.

One option might be to simply delete the 2nd part of that? The same 
construct appears in several similar sections below and I find them all 
confusing. The first sentence is clear in saying what the requirement is.

===
3.5.1

Trivial typo in the 2nd bullet

 >A Permission may have one or more assigner and/or assignee function 
roles undertaken by Party entities. Other types of function properties 
for Party may be used.

(Knock off the stray <)

If you like the rewording for the Permission ->asset link above, 
consider re-using it in this one too.

===

3.5.1

Grammar police:

"... , it must be valid (ie all it's constraints must be satisfied)" 
should be

"... , it must be valid (i.e. all its constraints must be satisfied)"

===

3.5.2

Again, inadvertent use of RFC 2119 keywords appear in

"A Prohibition class is a subclass of Rule that specifies the Actions 
that must not be performed..."

Be sure not to write MUST etc. in all caps 
(https://github.com/w3c/respec/wiki/User's-Guide#user-content-rfc-2119)

===

3.5.2

Same stray < at the beginning of

 >A Prohibition may have one or more assigner and/or assignee function 
roles undertaken by Party entities. Other types of function properties 
for Party may be used.


===

3.5.2

This sentence came unexpectedly: "Additionally, in case of any conflicts 
between Permissions and Prohibitions, the conflict property is set to 
perm indicating that the Permissions will take precedence."

Where is conflict defined? Link?

===

3.5.3

See above for repeated issues with:

A Duty may have an Asset via the target relation property on which the 
agreed Action must be performed. Other types of relation properties for 
Asset may be used.

It is assumed that any assigned Party has the appropriate permissions to 
perform the Duty Action.

 >A Duty may have one or more assigner and/or assignee function roles 
undertaken by Party entities. If the functional roles are not specified 
in the Duty, then the respective functions are assumed to be the same as 
in the referring Permission. Other types of function properties for 
Party may be used (for example, Compensated Party or Tracking Party).

===

3.5.3

Grammar police

"...  (ie agreed to be undertaken by the Parties..."

i.e should be written with full stops after the each letter,

===

3.6

First mention of an ODRL Processor (as yet undefined)

===
3.6.1

Typo


"... The second exmaple shows.."

(example)

===

3.6.2

Suggest that "Other operator values may be defined in the ODRL 
Vocabulary [vocab-odrl] or ODRL Profiles."

should be

"Other operator values are defined in the ODRL Vocabulary [vocab-odrl], 
further values may be defined by ODRL Profiles."

===

3.6.2

I don't think the word 'two' is necessary in

"The andSequence operator is an example where there are temporal 
conditional requirements between the two left and rigt operands."

===

3.6.2

" ODRL Processing systems..."

It would be more consistent to say ODRL Processors

===

3.6.2

I note that ODRL processors are expected to handle both IRIs and 
literals as values for left and right operand. Might be tricky.

===

3.7

Typo

"This example shows the atomic level of a Policy where it is a 
irreducible Rule..."

Should be

"This example shows the atomic level of a Policy where it is an 
irreducible Rule..." (a/an)

===

3.7

This section includes several ODRL Processor conformance criteria and, 
IMO, should be stated as such.

===

3.8

Consider using the term Policy Metadata cf Policy provenance. The word 
Provenance in a W3C spec usually refers to the Provenance ontology and 
related standards.

===

3.8, 3.9, 3.10

Again, lots of ODRL processor rules here.


Hope these comments help and don't throw too many spanners in the works.

Phil


-- 


Phil Archer
Data Strategist, W3C
http://www.w3.org/

http://philarcher.org
+44 (0)7887 767755
@philarcher1

Received on Friday, 12 May 2017 17:23:53 UTC