[oslc-core] Clarity on resource definitions (feedback on blank node vs reference resources NEEDED) (was: Tracked Resource Set: comments)

[Steve K Speicher]

I'm splitting up the response to your comments so I can get this out in 
front of the WG ahead of the meeting and since this clarifies the intent 
of a few items which could affect some implementations in flight.

Let me know IMMEDIATELY if there we a different read on the options below 
and if the proposed corrections cause implementation problems.  I do not 
see these as big shifts in the spec, just fixing up some missing edits. 
See details below:

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/ 

> > 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] 
They should all be true, not sure what happened here.  Perhaps editor(s) 
had it inverted, was in writable==False but clearly this was meant to all 
Read-only==True.
> 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. 
Yes this true and this approach is followed here.   There are a few 
properties that don't make sense with any other type of resource.  See 
suggested changes below
> 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]. 
See suggested changes below.  Either should be used.
> > 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. 
The table has a bug in it, it is intended to be Any (Local or Resource) 
for trs:changeLog.  The text needs to be updated to match. See below
> > "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. 
That is correct, intent is to be Resource + Reference.  Side note, the 
cutoff event is missing from the example and needs to be inserted.

Summary of the proposed changes to the resource description tables:
All
- Change Read-only to "True"
== Resource: TrackedResourceSet ==
trs:base
- none
trs:changeLog
- Change Value-type to Resource
- Change Representation to Either
rdfs:member
- Update description to say something such as "Or membership predicate 
otherwise indicated by ldp:membershipPredicate"
trs:cutoffEvent
- Change Value-type to Resource
- Change Representation to Either
== Resource: ChangeLog ==
trs:change
- Change Value-type to Resource
- Change Representation to Either
- trs:change range is trs:Creation, trs:Modification, trs:Deletion
trs:previous
- Change Representation to Either
Change "Each object of a trs:change triple is a Local Resource" to "Each 
object of a trs:change triple is a Resource"
rdf:type
- Change Representation to Reference
trs:changed
- Change Representation to Either
trs:order
- Change Representation to Either


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