[oslc-core] TRS spec comments & questions

[John Arwe]

I'm not one of the perpetrators ;-) of TRS, but I would be 'unsurprised' 
if we ended up using it at some point and hence I have some interest here 
too.

> TRS:   Paragraph 3: "Specifically the Tracked Resource Set 
representation will contain ...
I agree with Martin that "here be dragons". 
1: Compare "MUST contain the triples for the referenced Change Log (i.e., 
via a Blank Node, or an inline named Resource). " here against [1] where 
the value-type for a TrackedResourceSet's trs:changeLog predicate is 
Resource and Representation is Either.  According to [2] and [3], value 
type= Resource == URI reference (disallowing blank nodes).  To be fair, 
Representation == Either *does* permit a blank node.  [4] provides no 
convincing evidence either way.  Given the proximate examples that do use 
a blank node, I suspect you want value-type = AnyResource. 
2: "including the triples for the Change Events themselves enumerated in 
{TRS-URL, trs:change, ChangeEvent-URI}"  The TRS-URL "variable" conflicts 
with the examples and with [1].  Since this is in the exposition of an 
earlier MUST (in fact, the one under discussion in my 1:), it should 
probably be something like "change-log-identifier" instead. 
3: (this is probably a Core 3 cleanup item)  I see no definition of what 
"inline" as a representation actually means in [2] or [4].  Someone 
following their nose comes up empty there, in the only normative text. [3] 
says that inline => blank node, but I don't think that's correct, and 
we've said that vocabulary documents are non-normative in the past ... 
although I am aware that, this being an OSLC-defined term, it could be 
defined to mean what it currently says.  I think people's intuition 
however is that *any* triples can be inlined, not only a blank node's; if 
you want to hang on the 'can' vs 'must', consider hash-resources.  It 
might be simpler in the to just enumerate the valid combinations (hash, 
blank, uri resource) and the corresponding value-type+representation value 
to use.

> Base resources [5]
I suspect the authors were aware that LDP Paging is not yet stable and so 
chose to avoid it.  We split Paging from LDP in March; while it's still on 
the Rec track, it has not yet gone to Last Call so it is not suitable for 
implementations wanting a stable spec at this point in time.  We have 
(fading, in my case) hope that it will catch up to LDP; since it's a 
smaller spec, less implementation delay, so in theory possible.  It's less 
clear why they didn't just refer to OSLC Paging 2.0, which the material 
you quoted appears to re-state.

> Resources and rdf(s):range
I think I raised the "why do these not follow [2] which says [6]?" 
earlier, and was basically told to go mind my own business.  I'm more 
religious about following the open world assumption than most (which is 
why I ended up re-writing these parts of [2] and [6] a few years ago), and 
Core's consensus position has wobbled over time.  Like any non-universal 
rules, opinions will vary as to when exceptions are warranted.  Same way 
that many people read SHOULD as if it was MAY, which is quite different 
than it's 2119-defined intent.
Note that specifying Range-column values here has the semantics of [2], 
i.e. of a resource shape, which is about setting client code expectations 
in a specific usage context rather than contextless inferencing rules 
(rdfS:range).

> multiple values in the "range" column
For the "list of" semantic (since the rest is covered above for 
rdf(s):range), re-following my nose I can see how a reader could be unsure 
of the meaning.  [4] is the closest to being clear on the intent, when it 
says "possible resource types allowed".  I.e. the intent is to say that 
any combination of the listed types is permitted (including combinations, 
if those make sense).  I'm a proponent of [6] of course, so I read this as 
equivalent to the "It is likely ..." convention you cited.  Putting the 
list in Range I read as a "stronger hint" that servers might only accept 
those types (on input) and client might only observe those types (on 
output), but under an open world assumption it's still a hint.

>  ChangeLog: trs:order
+1 to both points

> Appendix B
I think the general intent of this section is to specify the 
machine-readable resource shapes equivalent to those in the tables.
In practice, I don't recall ever seeing it used.  Having two copies of the 
information begs for them to drift out of synch, (so far) both have been 
written lovingly by hand, and once out of synch there will be arguments 
about which governs (which has one of several trivial solutions: declare 
one to be non-normative in advance, declare which takes precedence, or 
declare that the WG must decide once the problem is discovered).
I will note that I have "inspired" some tooling to take either and 
generate the other.   We have started internal reviews to contribute that 
to Eclipse Lyo, since it can (amongst other things) speed up the drafting 
of the OASIS specs by automating some of the syntactic conversions.


[1] 
http://open-services.net/wiki/core/TrackedResourceSet-2.0/#TrackedResourceSet-Properties
[2] 
http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up=#OSLC_Defined_Resources
[3] http://open-services.net/ns/core/core.rdf
[4] 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA?sortcol=table;up=#oslc_ResourceShape_Resource
[5] 
http://open-services.net/wiki/core/TrackedResourceSet-2.0/#Base-Resources
[6] http://open-services.net/bin/view/Main/OslcCoreSpecAppendixLinks

Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead

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