See responses below, this adds on to my other response [6] and includes proposals for handle all your comments with the exception of 1 (looking for suggestions).
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/ > > Status: Finalizing Draft > What does this state mean? It is not one of those listed at [1]. [2] lists a different value. > Meta-question: I don't see [1] listed anywhere under [2]. Shouldn't it be there? That is out of date reference, see http://open-services.net/participate/workgroup-best-practices/ > > clients need not be aware of the Server’s criteria, and will instead discover a Resource Set’s members > This is "in order to use TRS" right, or at some low level? At a high level I think most clients (certainly not all) do have some notion about the set's inclusion criteria; that's how the client knows it's useful for some higher level purpose (like managing bugs). So they do often know it, it's just communicated through means outside TRS's scope. Response: correct, no spec change > > the Tracked Resource Set’s HTTP response MUST contain the triples for the referenced Change Log > This does not make any sense. It precludes any use for conditional requests, which the next sentence SHOULDs. > 1: I think you want to say that the representation Must contain... > 2: "the" triples could be any subset. Gut feeling is you're after more than that, but I'm fine if you're fine with "any subset" as the intent. > 3: A careful reader might interpret "for the referenced Change Log " to mean "for any triples of the form <TRS, *, *> for which a triple <TRS, rdf:type, trs:TrackedResourceSet> exists". The example could alternatively be read to imply that all the entries' (#1, #2, #3) triples might also be required, and (possibly) that those from any later segments must be included (of course doing so is illogical if one assumes the spec authors were careful, since doing so removes the need for segmentation). replace "HTTP response MUST" with "representation MUST" insert after "triples for the referenced Change Log" with some explanation which goes something like "of the form <TRS, *, *> for which a triple <TRS, rdf:type, trs:TrackedResourceSet> exist including the triples for the change events themselves enumerated in <TRS, trs:change, ChangeEvent> where the change events MUST be present in the TRS representation." Leaving to editor(s) to tweak the words as needed. > > The Server SHOULD also support etags, ... and relegate the Base to separate resources. > "relegate"? Suspect you're saying they should be distinct *HTTP* resources, but that does not follow as the only possible interpretation here. replace "and relegate the Base to separate resources" with "???" Proposals anyone? > > A Server MUST report a Resource modification event if a GET on it would return a semantically different response from previously. > Is this intended to give the server implementation flexibility, i.e. be intentionally vague ala etags rather than more prescriptive e.g. "if any of the returned RDF triples would differ"? If the definition of 'semantically different' is ambiguous, it's a pretty toothless Must. Which is fine, if that's the intent. Proposal: semantically different is: triples are modified in any of the cases: inserted triple, removed triple, triple replaced (new object/literal, e.g. changing boolean literal "true" to "false"), new predicate used (e.g. change from dc:title to rdfs:label) significant way and no significant difference is: align with above definition > > Segmentation > Why not just page them? Core has paging already, this appears to be incredibly similar ... a bit more restricted perhaps, but still. This was seen as having a couple of different qualities than regular OSLC paging: - you page backwards, newest changes first and go back in time - oslc:ResponseInfo class, sort of similar. Newer ldp:Page perhaps a little more similar - a change log segment is more descriptive and can be optimized for TRS usage (Others who have more background with these discussions have any more detail?) Proposal: no spec changes > > it is highly RECOMMENDED that a Server retain a minimum of seven days worth of Change Events. > Suggestion: use "strongly reco" ...it's a 2119 keyword I could not locate in 2119, though I've seen strongly used. Proposal: make suggested change > > 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] > 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. > 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]. Response: Handled in [6] > > 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. Response: Handled in [6] > > "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. Response: Handled in [6] > > ChangeLog resource def, "change" "sub-resource" > For the same reason we avoid restricting Ranges, we avoid restricting rdf:type cardinality and objects (although certainly on the latter we list the commonly expected ones). Proposal: align with rdf:type and trs:cutoffEvent, per resolution of [6] > > Client Behavior > Shouldn't this entire section be marked informative? Proposal: make informative > > An application declares the existence and location of a Tracked Resource Set with a service declaration of the following type: > 'service declaration' ?? citation please? The example has no context, it looks like you're just defining a standalone predicate - which would be fine, but that's all it is absent some other context. Proposal: replace " service declaration of the following type" with "statement of the following form" > > Servers MAY contain more than one statement with the property of trs:trackedResourceSet. > How do I model 'Server(s)' in RDF? Proposal: replace Servers MAY contain more than one statement with the property of trs:trackedResourceSet" with "Applications MAY provide multiple Tracked Resource Sets" > [1] http://open-services.net/bin/view/Main/OslcWorkgroupPrinciplesandBestPractices?sortcol=table;up=#What_are_the_phases_of_specifica > [2] http://open-services.net/wiki/core/ > [3] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA?sortcol=table;up=#oslc_ResourceShape_Resource > [4] http://open-services.net/wiki/core/CoreVocabulary/#LocalResource > [5] http://open-services.net/wiki/core/CoreVocabulary/#Inline [6] http://open-services.net/pipermail/oslc-core_open-services.net/2013-May/001646.html
