[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