[oslc-core] Tracked Resource Set: comments

[John Arwe]

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?

> 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.

> 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).

> 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.

> 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.

> Segmentation
Why not just page them?  Core has paging already, this appears to be 
incredibly similar ... a bit more restricted perhaps, but still.

> 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

> 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].

> 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.

> "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.

> 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).

> Client Behavior
Shouldn't this entire section be marked 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.

> Servers MAY contain more than one statement with the property of 
trs:trackedResourceSet.
How do I model 'Server(s)' in RDF?



[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



Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20130513/240bc7db/attachment-0003.html>