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: [email protected] 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
