[oslc-core] Updated ChangeLog Proposal
Frank Budinsky
frankb at ca.ibm.com
Mon Mar 21 14:12:17 EDT 2011
> IMO, It is important to put "oslc:nextPage rdf:nil" to end the ...
I think we'd need to add something like oslc:nilPage for this purpose
because rdf:nil is defined to be an instance of rdf:List, which pages are
not.
Should we open this as a separate issue? Do we need to keep the ChangeLog
compliant with the current OSLC paging model (i.e., have no nextPage
property on the last page) or can we link these issues?
Frank.
Martin Nally/Raleigh/IBM wrote on 03/18/2011 01:45:46 PM:
> [image removed]
>
> Re: Updated ChangeLog Proposal
>
> Martin Nally
>
> to:
>
> Frank Budinsky
>
> 03/18/2011 01:46 PM
>
> Cc:
>
> oslc-core, RELM Development
>
> >> i.e., a broken reference ends the pages entries, instead of a
nilreference
>
> I would not describe it as a "broken reference". It's a valid, un-
> broken reference to a valid resource for which no information is
> provided on the current page. Information about that resource is on
> the next page (and possibly also available through GET, but you
> would not want to go that route for indexing use-cases). The indexer
> algorithm should be to process all the triples on each page, and
> then go to the next page. The indexer knows to go to the next page
> when it finds a link to a list for which the page contains no
> information - that information must be on the next page. The indexer
> can stop when a) there are no more pages b) it finds information on
> one page - like a previously-processed change entry - that causes it
> to lose interest in the information that might be on subsequent pages.
>
> Your pagination example is as I would have written it too.
>
> IMO, It is important to put "oslc:nextPage rdf:nil" to end the
> chain. Otherwise a client should assume that there might be more
> pages and the information saying what the next one is can be found
> somewhere else. Unfortunately the current Core spec says otherwise.
>
> Best regards, Martin
>
> Martin Nally, IBM Fellow
> CTO and VP, IBM Rational
> tel: +1 (714)472-2690
>
> From:
>
> Frank Budinsky/Toronto/IBM at IBMCA
>
> To:
>
> Martin Nally/Raleigh/IBM at IBMUS
>
> Cc:
>
> oslc-core at open-services.net, RELM Development
>
> Date:
>
> 03/18/2011 01:16 PM
>
> Subject:
>
> Re: Updated ChangeLog Proposal
>
> Hi Martin,
>
> Very interesting idea. Instead of pages of "partial lists of change
> entries", we have pages of "list entries". I guess it's a little
> harder for clients to know when to check for a next page (i.e., a
> broken reference ends the pages entries, instead of a nil reference)
> but otherwise it's much cleaner.
>
> > Pagination of this resource according to our standard algorithm is
> a trivial exercise left to the reader.
>
> Here it is, just to make sure I'm capable of doing the trivial
exercise :-)
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> PAGE 1
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> @prefix oslc: <http://open-services.net/ns/core#> .
> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix : <https://.../ChangeLog#>.
>
> <https://.../ChangeLog?oslc.paging=true>
> oslc:nextPage <https://.../ChangeLog?pageno=2> .
> <https://.../ChangeLog> oslc:changes :b1.
> :b1 rdf:first
> [ a oslc:create ;
> oslc:changed <https://.../com.ibm.team.workitem.WorkItem/23> ;
> oslc:at "103"^^xsd:int
> ] ;
> rdf:rest :b2 .
> :b2 rdf:first
> [ a oslc:update ;
> oslc:changed <https://.../com.ibm.team.workitem.WorkItem/22> ;
> oslc:at "102"^^xsd:int
> ] ;
> rdf:rest :b3 .
> :b3 rdf:first
> [ a oslc:delete ;
> oslc:changed <https://.../com.ibm.team.workitem.WorkItem/21> ;
> oslc:at "101"^^xsd:int
> ] ;
> rdf:rest :b4 .
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> PAGE 2
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> @prefix oslc: <http://open-services.net/ns/core#> .
> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix : <https://.../ChangeLog#>.
>
> <https://.../ChangeLog?pageno=2>
> oslc:nextPage rdf:nil . <<<<<<<<< or omit the nextPage property
entriely
> :b4 rdf:first
> [ a oslc:create ;
> oslc:changed <https://.../com.ibm.team.workitem.WorkItem/20> ;
> oslc:at "100"^^xsd:int
> ];
> rdf:rest rdf:nil .
> Thanks,
> Frank.
>
> From:
>
> Martin Nally/Raleigh/IBM at IBMUS
>
> To:
>
> Frank Budinsky/Toronto/IBM at IBMCA
>
> Cc:
>
> oslc-core at open-services.net, RELM Development
>
> Date:
>
> 03/18/2011 11:27 AM
>
> Subject:
>
> Re: Updated ChangeLog Proposal
>
> This may seem like a small, arcane point, but it's been bugging me.
> It concerns pagination of the changelog.
>
> OSLC's normal strategy for pagination is very simple and elegant.
> Every RDF resource's state is composed of a graph of triples.
> "Graph" is just RDF's name for what any middle-school math student
> would call a set (don't ask, I've no idea). Sets can be divided
> arbitrarily into discrete subsets, so if you want to paginate an RDF
> resource, all you do is divide up the triples into discrete subsets
> and return each subset in the representation of a page. The beauty
> is that the triples themselves are totally unchanged. The Page
> itself is not the subject of any triples except nextPage (and maybe
> a description).
>
> The wrinkle in this approach is caused by blank nodes. Blank nodes
> cannot be referenced outside the page they are on, so if any of
> those triples includes a blank node as its subject or object, it has
> to go on the same page (in the same subset) as every other triple
> that references the same blank node. Because of the way RDF lists
> are represented, the lists themselves are almost always blank nodes
> (a list has only two references, to "first", which is a useful node,
> and to "rest" which is another list containing the rest of the
> conceptual list). Because the blank nodes point to each other in a
> chain, they cannot be split across pages, and so the whole list ends
> up in the same page.
>
> The way we resolved this in Frank's ChangeLog design was to make
> each page of the changelog have a list of change entries. This
> clearly works, but it means the triples for the pages are different
> from the triples for the changelog itself, which is a more complex
> and less pleasing pattern.
>
> It occurred to me this morning that there is a way to use our
> standard pagination technique to paginate the changelog without
> introducing a new mechanism. It works like this.
>
> Normally the changelog whose URL is <https://.../ChangeLog#> looks like
this:
>
> @prefix oslc: <http://open-services.net/ns/core#> .
> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
>
> <https://.../ChangeLog>
> oslc:changes (
> [ a oslc:create ;
> oslc:changed <https://.../com.ibm.team.workitem.WorkItem/23> ;
> oslc:at "103"^^xsd:int
> ]
> [ a oslc:update ;
> oslc:changed <https://.../com.ibm.team.workitem.WorkItem/22> ;
> oslc:at "102"^^xsd:int
> ]
> [ a oslc:delete ;
> oslc:changed <https://.../com.ibm.team.workitem.WorkItem/21> ;
> oslc:at "101"^^xsd:int
> ]) .
> This is Turtle shorthand for the following. Note that I'm not
> changing anything here, I'm just expanding the shorthand:
>
> @prefix oslc: <http://open-services.net/ns/core#> .
> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>
> <https://.../ChangeLog> oslc:changes _:b1.
> _:b1 rdf:first
> [ a oslc:create ;
> oslc:changed <https://.../com.ibm.team.workitem.WorkItem/23> ;
> oslc:at "103"^^xsd:int
> ].
> _:b1 rdf:next _:b2
> _:b2 rdf:first
> [ a oslc:update ;
> oslc:changed <https://.../com.ibm.team.workitem.WorkItem/22> ;
> oslc:at "102"^^xsd:int
> ].
> _:b2 rdf:next _:b3
> _:b3 rdf:first
> [ a oslc:delete ;
> oslc:changed <https://.../com.ibm.team.workitem.WorkItem/21> ;
> oslc:at "101"^^xsd:int
> ].
> _:b3 rdf:next rdf:nil .
>
> Since I have not changed anything, this still can't be paginated in
> the usual manner. However, if I make the following change, it can be:
>
> @prefix oslc: <http://open-services.net/ns/core#> .
> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix : <https://.../ChangeLog#>.
>
> <https://.../ChangeLog> oslc:changes :b1.
> :b1 rdf:first
> [ a oslc:create ;
> oslc:changed <https://.../com.ibm.team.workitem.WorkItem/23> ;
> oslc:at "103"^^xsd:int
> ].
> :b1 rdf:rest :b2
> :b2 rdf:first
> [ a oslc:update ;
> oslc:changed <https://.../com.ibm.team.workitem.WorkItem/22> ;
> oslc:at "102"^^xsd:int
> ].
> :b2 rdf:rest :b3
> :b3 rdf:first
> [ a oslc:delete ;
> oslc:changed <https://.../com.ibm.team.workitem.WorkItem/21> ;
> oslc:at "101"^^xsd:int
> ].
> :b3 rdf:rest rdf:nil .
>
> Pagination of this resource according to our standard algorithm is a
> trivial exercise left to the reader. The only special rule of
> pagination for ChangeLog would be that the entries on a particular
> page are all older than the entries on the previous page and younger
> than the ones on the following page. This notation is slightly
> harder for a human to read than Turtle's () notation, but is neither
> better nor worse for a computer to read - it produces the same
> pattern of triples.
>
> Note that this change causes https://.../ChangeLog#b1 through b3 to
> become legitimate URLs. This does not necessarily mean that the OSLC
> implementer has to honor a GET on these URLs - it's perfectly OK for
> the URLs to be used in the list but not actually be independently
> GETable - but the implementation may also choose to honor a GET.
> This also gives a different and maybe more satisfactory way for a
> changelog to make a real resource out of each change entry. Frank
> did the obvious thing of allowing the entry itself to be a resource,
> but this creates some ambiguities and special rules, as I pointed
> out in my last note. If instead it was the list nodes that are given
> URLs, and the entries remain always as blank nodes, it might be
> easier to understand. In practice, an implementation would be more
> likely to use https://.../ChangeLog#b103 through https://.../ChangeLog#
> b101 as URLs for the lists corresponding to entries of the matching
> sequence number.
>
> Best regards, Martin
>
> Martin Nally, IBM Fellow
> CTO and VP, IBM Rational
> tel: +1 (714)472-2690
>
> From:
>
> Frank Budinsky/Toronto/IBM at IBMCA
>
> To:
>
> oslc-core at open-services.net
>
> Cc:
>
> Martin Nally/Raleigh/IBM at IBMUS, RELM Development
>
> Date:
>
> 03/17/2011 11:57 AM
>
> Subject:
>
> Updated ChangeLog Proposal
>
> Hi All,
>
> I've uploaded the latest version of the OSLC change log proposal here:
>
>
http://open-services.net/pub/Main/IndexingProposals/OSLC_indexing_0316.doc
>
> It includes changes to reflect discussion and decisions made during
> the first round of review, including the following:
>
> A section to describe the motivating use case.
> Description of a formal "Indexing Profile" which defines the
> capabilities that a service provider MUST support in order to be
indexable.
> Proposed formal scope of indexing/changeLog.
> ChangeLog entry timestamps changed to sequence numbers.
> ChangeLog entries can optionally be referenced URI-addressable resources.
>
> Please send comments and issues to the mailing list. We're also
> tentatively scheduled to discuss this during the OSLC Core Workgroup
> call, next week, so hopefully we can hash out most of the remaining
> issues by then.
>
> Thanks,
> Frank.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110321/42022c85/attachment-0003.html>
More information about the Oslc-Core
mailing list