Jim, Thanks for your comments, I've addressed your comments below and sending to oslc-core mailing list as this impacts the TRS spec.
See insertion of proposals from myself and Vivek below... Jim and ALL, Some of the proposals tighten the restrictions to what was intended and may affect implementation. Please review carefully and show support (respond with +1) or indicate what issues there might be with this (explaining what those issues might be). We are not meeting next week (July 3rd) so I'd like to try to handle this offline. Thanks, Steve Speicher IBM Rational Software OSLC - Lifecycle integration inspired by the web -> http://open-services.net Jim des Rivieres/Ottawa/IBM wrote on 06/12/2013 03:02:50 PM: > From: Jim des Rivieres/Ottawa/IBM@IBMCA > To: Steve K Speicher/Raleigh/IBM@IBMUS > Cc: Frank Budinsky/Toronto/IBM@IBMCA > Date: 06/12/2013 03:07 PM > Subject: Re: Help with a Tracked Resource Set comment > > Hi Steve, The earliest designs were that a TRS was not required to have a > Base - it was perfectly fine to have just the Change Log part. A pure change > log. This would correspond to a TRS where trs:base is omitted. It is also > semantically meaningful to have a TRS that has a Base and no Change Log. A > pure resource enumeration. This would correspond to a TRS where > trs:changeLog is omitted. > > As I read the early text and the later tables, I see some contradictions. > Good context, not sure why some things diverged. Read on to see how we are handling... > "A Tracked Resource Set MUST provide references to the Base and Change Log > using the trs:base and trs:changeLog predicates respectively." > > But in the TrackedResourseSet Properties table, spec shows trs:base as > exactly-one, and trs:changeLog as zero-or-one. > I'd propose that we change trs:changeLog to exactly-one, as you indicate an empty trs:changeLog by not omitting it but setting it instead to rdf:nil. A pattern done for other notions of "page intentionally left blank". > I'm puzzled by a couple of other things in table: > > trs:base > Representation should probably be "Reference" instead of "either" - i.e., a > separate resource. This would address the "relegated to a separate > resource" issue. Also, shouldn't Range be "ldp:AggregateContainer" instead > of "any", or is that overly specific? I think it was set to "either" to be the most wide open and unrestrictive. Though I can't see a case where it would ever be anything other than "Reference". I propose we change to "Reference". On the range, I'd propose updating it to be 'ldp:Container' (in LDP we remove the notion of Aggregate vs Composite containers, it is just ldp:Container now and matches more closely the aggregate model). > > What does it mean for Read-Only to be True for trs:base but False for > trs:change-log? (I don't think I understand the "Read-Only" means in this context.) I missed editing this when I mostly fixed the "Read-Only" table problems from before, so I just fixed it. > Regards, > Jim
