[oslc-core] Help with a Tracked Resource Set comment

Steve K Speicher sspeiche at us.ibm.com
Thu Jun 27 15:31:28 EDT 2013


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 at IBMCA
> To: Steve K Speicher/Raleigh/IBM at IBMUS
> Cc: Frank Budinsky/Toronto/IBM at 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




More information about the Oslc-Core mailing list