> From: Dave <[email protected]> > To: oslc-core <[email protected]> > Date: 12/01/2010 12:40 PM > Subject: [oslc-core] oslc:totalSize Clarification > Sent by: [email protected] > > I will write up the various paging-related issues we've been > discussing, but I'd like to get this one on the table first. > > Currently, we define a property of oslc:ResponseInfo named > oslc:totalSize, which has occurrence of zero-or-one. We define this > as: "Total number of results across all pages, its value should be > non-negative" and thus are not clear about what we are counting. > > The consensus in the work-groups is that we meant to say something > like "total number of top-level resources returned across all pages" > or "total number of member property values returned across all pages" > and refer to the query spec for the definition of member property. > But, in today's meeting we forgot about the fact that oslc:totalSize > can be returned for not just query resource but also in "plain old" > resources and in such a plain old resource, seems to me, the only > thing oslc:totalSize could mean is total count of triples. >
I think the usage is similar if we think about the representation response that is being paged. The subject of the triples are the same, then it is really the same. > Perhaps, what we need to do is to cover both of these cases, something > like this: > > oslc:totalSize - Total number of results across all pages, its value > should be non-negative. In the context of a query resource, this value > is the total number of member property values that match the query. In > the context of other resources, the value is the total number of > property values (i.e. RDF triples) of the resource. > > Ideas? I went looking for what SPARQL SELECT count() says, since I would assume it is what would be used to implement this. Though this is a common extension to SPARQL and not in the specification, so you have to look at places like Jena ARQ [1]. Though this definition matches what we mean, it is still a bit unclear. Having said that, I can't come up with anything better than what you have at the moment. My only concern is "member property values that match the query", which to most people would be "rows". [1] http://jena.sourceforge.net/ARQ/group-by.html - Steve
