[poe] Issue: Model Comments/Feedback (PhilA) marked as To Be Closed

riannella has just labeled an issue for https://github.com/w3c/poe as "To Be Closed":

== Model Comments/Feedback (PhilA) ==
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.

See https://github.com/w3c/poe/issues/181

Received on Tuesday, 6 June 2017 06:30:09 UTC