[oslc-core] TRS spec comments & questions

[Martin P Pain]

I just had a read through the TRS spec, and have these (mostly editorial) 
comments & questions:

URL: http://open-services.net/wiki/core/TrackedResourceSet-2.0/

Intro:
  - Is the "finalizing draft" status still correct?
  - Nothing on the core wiki page (by the TRS link) or the TRS spec page 
mentions OASIS, so I presume this is still the definitive location for TRS 
2.0.


TRS:
  Paragraph 3: "Specifically the Tracked Resource Set representation will 
contain a triple {TRS-URL, rdf:type, trs:TrackedResourceSet} including the 
triples for the Change Events themselves enumerated in {TRS-URL, 
trs:change, ChangeEvent-URI} where the Change Events MUST be present in 
the Tracked Resource Set’s representation." - This isn't very clearly 
worded. And I think the subject for the trs:change triple is wrong. Should 
this be: "Specifically the Tracked Resource Set representation MUST 
contain: a triple {TRS-URI, rdf:type, trs:TrackedResourceSet}, a triple 
{TRS-URI, trs:changeLog, ChangeLog-URI} (where ChangeLog-URI may be an 
inline resource/blank node), the triples pointing to the Change Events 
themselves as {ChangeLog-URL, trs:change, ChangeEvent-URI}, and all 
triples whose subject is any of the referenced Change Events."?


Base resources:
    - "The Base MAY be broken into multiple pages in which case the Server 
will respond with a 30x redirect message, directing the Client to the 
first “page resource”. The representation of a page resource will contain 
a subset of the Base’s membership triples. In addition, it will contain 
another triple, whose subject is the page resource itself (i.e., not the 
Base resource), with a reference to the next page:" - shouldn't this just 
refer to LDP-paging? Or is it less "at-risk" if we leave these 
descriptions in here?


Resources:
  - Was it the intention to set the "rdf:range" of the properties? Which 
implies that type on any target (i.e. creates an inference rule), not 
restricts the targets to that type. The convention I'm aware of is to say 
"any" in the "range" column, and say in the description "the target [is 
expected to be|MUST be] of type X" (with the "expect to be..." form the 
best one, as it allows for future extension based on types, but requires 
clients to check the rdf:types of the resources they receive, unlike the 
range assertion - but surely that's good practice anyway...).


  Base:
    - "trs:cutoffEvent": I believe multiple values in the "range" column 
asserts an inference rule that all targets of that property have ALL those 
types, which is not the intention here.


  ChangeLog:
    - "trs:change": Same as cutoffEvent above.
    - "trs:order": I'd suggest "non-negative" being in the description, 
not in the "value-type" column, as it can't be mapped to a resource shape 
"value-type" option. (I believe these tables' format is based on the idea 
of a resource shape).
    - "trs:order": Representation should be "n/a"


"Appendix B: Resource shapes":
  - Arguably those tables under "Resources" are descriptions of resource 
shapes.



Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
OASIS Open Services for Lifecycle Collaboration - Automation technical 
committee chair

E-mail: martinpain at uk.ibm.com
Find me on:  and within IBM on:  




IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20140610/6ed1799f/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 518 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20140610/6ed1799f/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1208 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20140610/6ed1799f/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20140610/6ed1799f/attachment.gif>