[oslc-core] Tracked Resource Set: comments
Steve K Speicher
sspeiche at us.ibm.com
Mon May 20 17:39:36 EDT 2013
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 at IBMUS
To: oslc-core at open-services.net
Date: 05/13/2013 03:37 PM
Subject: [oslc-core] Tracked Resource Set: comments
Sent by: "Oslc-Core" <oslc-core-bounces at open-services.net>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20130520/f15f6dc4/attachment-0003.html>
More information about the Oslc-Core
mailing list