I'm splitting up the response to your comments so I can get this out in front of the WG ahead of the meeting and since this clarifies the intent of a few items which could affect some implementations in flight.
Let me know IMMEDIATELY if there we a different read on the options below and if the proposed corrections cause implementation problems. I do not see these as big shifts in the spec, just fixing up some missing edits. See details below: Thanks, Steve Speicher IBM Rational Software OSLC - Lifecycle integration inspired by the web -> http://open-services.net From: John Arwe/Poughkeepsie/IBM@IBMUS To: [email protected] Date: 05/13/2013 03:37 PM Subject: [oslc-core] Tracked Resource Set: comments Sent by: "Oslc-Core" <[email protected]> > http://open-services.net/wiki/core/TrackedResourceSet-2.0/ > > Resource definitions (general comments) > 1: Read-only is False in all cases. In other words server implementations are generally expected to make all these triples writable. Not seeing why anything stronger than unspecified is needed at first blush, and as potential implementers I'd actually expect most will be r/o (True) not client-writable. [3] They should all be true, not sure what happened here. Perhaps editor(s) had it inverted, was in writable==False but clearly this was meant to all Read-only==True. > 2: Range is often filled in. I thought the current thinking was to "almost always" leave it core:Any, and list in the description the concrete types a client would commonly expect/hence "should" code for. Yes this true and this approach is followed here. There are a few properties that don't make sense with any other type of resource. See suggested changes below > 3: "n/a" representations for Resource value types is not a valid combination. If the goal is to be open, use Either. Although in cases where you truly want Local resources only, [4] appears to imply the only possible representation is Inline [5]. See suggested changes below. Either should be used. > > Tracked Resource Set resource def > Table says Resource = Local [4], Representation = Inline [5] for trs:changeLog. Text says "contain the triples for the referenced Change Log (i.e., via a Blank Node, or an inline named Resource) " which is actually more than what the table allows. Why are we in the business of caring how servers represent the resources here? If the requirement is that the CL triples come back on the TRS GET, fine that's covered in text. I should be able to name (identify) the CL anything I like as long as you get your steenkin triples back when/where the spec says you need them. The table has a bug in it, it is intended to be Any (Local or Resource) for trs:changeLog. The text needs to be updated to match. See below > > "base" resource def > 1: This could be read to suggest that rdfs:member is the only predicate that can be used to enumerate the set. Is this true, or (as the examples might also suggest) it is a general ldp:Container implying that the membership predicate can vary by container? > 2: Table says Resource = Local [4], Representation = Inline [5] for trs:cutoffEvent, and range is filled in (consistent so far). Examples however do not show blank nodes (as both [4] and [5] require according to the core vocabulary document). Suspect you want Resource + Reference, which is the standard enum pattern. That is correct, intent is to be Resource + Reference. Side note, the cutoff event is missing from the example and needs to be inserted. Summary of the proposed changes to the resource description tables: All - Change Read-only to "True" == Resource: TrackedResourceSet == trs:base - none trs:changeLog - Change Value-type to Resource - Change Representation to Either rdfs:member - Update description to say something such as "Or membership predicate otherwise indicated by ldp:membershipPredicate" trs:cutoffEvent - Change Value-type to Resource - Change Representation to Either == Resource: ChangeLog == trs:change - Change Value-type to Resource - Change Representation to Either - trs:change range is trs:Creation, trs:Modification, trs:Deletion trs:previous - Change Representation to Either Change "Each object of a trs:change triple is a Local Resource" to "Each object of a trs:change triple is a Resource" rdf:type - Change Representation to Reference trs:changed - Change Representation to Either trs:order - Change Representation to Either
