[oslc-core] New OSLC ChangeLog Proposal

[Steve K Speicher]

> From: Frank Budinsky <frankb at ca.ibm.com>
> To: oslc-core at open-services.net
> Cc: Martin Nally/Raleigh/IBM at IBMUS
> Date: 12/20/2010 10:47 AM
> Subject: [oslc-core] New OSLC ChangeLog Proposal
> Sent by: oslc-core-bounces at open-services.net
> 
> Hello,
> 
> Nick Crossley and I would like to submit a proposal for adding a 
ChangeLog 
> service to the OSLC core specification. This new service will be key to 
the 
> success of an indexer, and therefore we would like to queue it up for 
> discussion as soon as possible in January. 
> 
> The OSLC proposal, itself, is described in section 1.5 of the attached 
> document, while the rest of the document describes an indexer prototype, 

> including how it intends to use the change log.
> 
> (See attached file: RDF_indexer_overview_1220.doc)
> 
> Any comments/feedback on the new proposal or the indexer prototype 
itself 
> would be very welcome.
> 

Hi Frank,

Proposal seems quite simple and workable.  Some initial comments on the 
proposal:

Though I would have expected that a client could request a date range for 
the change log, or simply "changes since some date time".  Whether some of 
the query syntax could be used or simply using name-value pair on 
changelog service URI such as ?oslc.since=mmddyy or something.

Why is an ordered collection important if you have oslc:at (timestamp) 
with each entry?  Is it expected that clients need to validate oslc:at 
match the order?  I suspect the answer is that in order for the indexer to 
properly process paged responses, it would like to start with first page 
received and not have to fetch all pages to validate order.

Would you expect that each occurrence (change event) be possibly a 
URI-addressable resource itself?  Proposal seems to imply it is not in 
your proof of concept but could imagine implementations where it is.  Not 
sure there is any issue with this, just an observation that may be worth 
noting.

It would be interesting when we have this discussion to look at the 
scenarios where we are interested in change log for a given resource, for 
example "history of a defect", to see how these models should compliment 
each other.  As Olivier alluded to in his response, there could be cases 
where it might be helpful to extend this to include more detail about the 
change.

Would be good to stick to Dublin Core, for example dc:date instead of 
oslc:at.   Not sure there are good matches for any of the other 
properties.

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645