TRS spec comments & questions

[Martin P Pain <martinpain@uk.ibm.com>]

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@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