Following up on Steve's suggestion that it should be permissible for change events to be real resources, we might clarify that indexing clients need to be able and willing to accept this:
@prefix oslc: <http://open-services.net/ns/core#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . <https://.../ChangeLog> oslc:changes (https://.../changeEvent/22 https://.../changeEvent/21 https://.../changeEvent/20). https://.../changeEvent/22 a oslc:create ; oslc:changed <https://.../com.ibm.team.workitem.WorkItem/23> ; oslc:at "2010-12-02T21:28:48.064Z"^^xsd:dateTime. https://.../changeEvent/21 a oslc:update ; oslc:changed <https://.../com.ibm.team.workitem.WorkItem/22> ; oslc:at "2010-12-02T21:25:57.299Z"^^xsd:dateTime. https://.../changeEvent/20 a oslc:delete ; oslc:changed <https://.../com.ibm.team.workitem.WorkItem/21> ; oslc:at "2010-12-02T21:22:54.72Z"^^xsd:dateTime. Less clear is whether they need to be able and willing to accept this: @prefix oslc: <http://open-services.net/ns/core#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . <https://.../ChangeLog> oslc:changes (https://.../changeEvent/22 https://.../changeEvent/21 https://.../changeEvent/20). The implication of accepting this is that the client is willing to perform a GET on each change event individually. Another interesting issue might be the use of https. I believe that using https means that proxy servers can't cache changelog pages. Is that what we want to encourage? Best regards, Martin Martin Nally, IBM Fellow CTO and VP, IBM Rational tel: +1 (714)472-2690 |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Frank Budinsky/Toronto/IBM@IBMCA | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Martin Nally/Raleigh/IBM@IBMUS | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Cc: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[email protected], Steve K Speicher/Raleigh/IBM@IBMUS | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |01/04/2011 12:23 PM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Re: [oslc-core] New OSLC ChangeLog Proposal | >--------------------------------------------------------------------------------------------------------------------------------------------------| Thanks for the feedback Steve. I added a couple more comments after Martin's. See <FB></FB> Thanks, Frank. |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Martin Nally/Raleigh/IBM@IBMUS | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Steve K Speicher/Raleigh/IBM@IBMUS | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Cc: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Frank Budinsky <[email protected]>, [email protected] | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |01/04/2011 10:16 AM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Re: [oslc-core] New OSLC ChangeLog Proposal | >--------------------------------------------------------------------------------------------------------------------------------------------------| See <mn></mn> Best regards, Martin Martin Nally, IBM Fellow CTO and VP, IBM Rational tel: +1 (714)472-2690 |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Steve K Speicher/Raleigh/IBM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Frank Budinsky <[email protected]> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Cc: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Martin Nally/Raleigh/IBM@IBMUS, [email protected] | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |01/04/2011 09:50 AM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Re: [oslc-core] New OSLC ChangeLog Proposal | >--------------------------------------------------------------------------------------------------------------------------------------------------| > From: Frank Budinsky <[email protected]> > To: [email protected] > Cc: Martin Nally/Raleigh/IBM@IBMUS > Date: 12/20/2010 10:47 AM > Subject: [oslc-core] New OSLC ChangeLog Proposal > Sent by: [email protected] > > 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. <mn>Several people have requested this. The current thinking is that so long as the pages are inverse-time-ordered, clients have enough mechanism already to satisfy this need. So far this has indeed been adequate for the prototype implementation. I would prefer to avoid adding more options until we have a client that can explain in detail why the current solution is inadequate.</mn> <FB>We also think that adding an optimization like this in the future would be simple. Removing or changing it later would be much harder.</FB> 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. <mn>Interesting point. I think there are two possible conceptual models. One is that a change-log is inherently time-ordered. In that model, you would expect the representation to reflect that characteristic, and you would not need features like "?oslc.since=mmddyy" since retrieving the pages in reverse time order gives you the same result. This is the conceptual model that underpins the current proposal. The other conceptual model is that the change log is just a set of entries with time-stamps, which is the mental model you seem to be working with. Features like " ?oslc.since=mmddyy" are necessary in that model to select a subset that has the characteristic that all other entries are guaranteed to be older or younger than all the entries in the subset. I think your model is probably a workable alternative. I can't think of a compelling reason for adopting one over the other, although my bias is still towards the current proposal.</mn> <FB>A possible benefit of the current proposal is that it might be simpler and/or more efficient for a service provider to truncate the ChangeLog if the entries are maintained in a time ordered list.</FB> 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. <mn>The current design does not preclude URI-addressable change entries, but does not require them. If a client had to GET the change events individually to access their properties, it would have a significant performance impact.</mn> 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. <mn>Changelogs have been around for a long time, and the scenarios they are used for are fairly well understood. It's not conventional to try to implement resource-specific change logs, and I'd be nervous about going down that path. Also, if you start to put "detail" in a change log, you will have to invent a security model for the change-log, which I think will lead to complexity. I don't think we should go there.</mn> Would be good to stick to Dublin Core, for example dc:date instead of oslc:at. <mn>Yes, I like that idea.</mn> Not sure there are good matches for any of the other properties. <FB>Thanks for pointing this out. I'll make this change right away.</FB> Thanks, Steve Speicher | IBM Rational Software | (919) 254-0645
