[oslc-core] Tracked Resource Set: comments
John Arwe
johnarwe at us.ibm.com
Mon May 13 15:36:41 EDT 2013
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-0001.html>
More information about the Oslc-Core
mailing list