Overall size of collection

47 views
Skip to first unread message

John Leedham

unread,
Mar 28, 2017, 8:50:46 AM3/28/17
to Collection+JSON
Hello all,

I am just putting together some work for a search system, and given the number of results, we obviously need to page it. However, it would be nice to indicate to the user from the first page of results how many there are in total either specifically, or "roughly".

I could sort of do this by having a link to the "last" page of results and have the user do some parsing of the URL and multiplication of pages*result per page, but this seem against the spirit of making it machine processable.

Has this been done before? In essence, is there scope for some sort of 'collection level property' to put a hits count in or is there another approach that could work?

Thanks for any suggestions,

John

mca

unread,
Mar 28, 2017, 2:25:15 PM3/28/17
to collect...@googlegroups.com
i've added "page-level" properties to a cj document before:

There is also an extension for a value object that might be useful (though it it not used quite in the way you need, i think):
https://github.com/collection-json/extensions/blob/master/value-types.md

I'd hesitate to create a page-specific feature within Cj, but a general way to describe interesting data (e.g. a property or value object) at the top level seems useful.




--
You received this message because you are subscribed to the Google Groups "Collection+JSON" group.
To unsubscribe from this group and stop receiving emails from it, send an email to collectionjson+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

John Leedham

unread,
Mar 29, 2017, 11:14:47 AM3/29/17
to Collection+JSON
Thanks for the steer. 

So I can see the 'properties' dictionary works OK, since it's backwards compatible with the main specification. I agree as a general approach, having collection level properties is a useful addition to the spec. I wonder whether they should go into more of the { name: page_count  value=25 } rather than { page_count : 25 } in order to fit better with the item->data properties

I think the use case is perhaps not uncommon, so it might be nice to define some standard properties. In fact more generally, is there any equivalent registry to the "link relations" for property names? E.g. to standardise "hits" vs "matches" or "page_count" vs "pages".

Thanks again for your feedback,

John

To unsubscribe from this group and stop receiving emails from it, send an email to collectionjso...@googlegroups.com.

mca

unread,
Mar 29, 2017, 11:19:50 AM3/29/17
to collect...@googlegroups.com
John:

hmmm.. good point.

maybe we need to define an object at the page level ("properties", "metadata", etc.) that can contain one or more "data" elements.

that way, we reuse the data element design, support the additional metadata (as you mention) and even make it possible to add safely add extension properties to the data elements.

as long as we give some guidance in the extension that this SHOULD NOT be used to override the "items" design element.

does that make sense?





To unsubscribe from this group and stop receiving emails from it, send an email to collectionjson+unsubscribe@googlegroups.com.

John Leedham

unread,
Apr 24, 2017, 8:28:43 AM4/24/17
to Collection+JSON
Hi Mike,

Many apologies for not concluding this discussion - I went away on holiday for a couple of weeks and completely forgot where I'd got to.

I'm happy with something along these lines (although I'm not sure about whether "hits" is a good choice - we're using it for the time being, but I can't see anything I like better in https://www.iana.org/assignments/link-relations/link-relations.xhtml

    "properties": [
      {
        "prompt": "Number of matching documents",
        "name": "hits",
        "value": 87
      }
    ]

Maybe "count" instead of "hits"? Not sure.

Thanks for your help,

John

mca

unread,
Apr 24, 2017, 3:57:26 PM4/24/17
to collect...@googlegroups.com
John:

yeah, i think this would be a good extension to have. essentially, we need a write up of the "properties" element at the root of a Cj document. that it MAY appear and that it MAY have one or more data elements within it. I think doing that way makes the existing data element more useful w/o adding a new object to the burden of parsing Cj documents.

if you use the data element as the contents of the properties collection, you'll inherit all the value (and burden?) of making sure it is a value data element (id, name, prompt, value, etc.) but i think that still works. 

does that make sense? and, if yes, are you ok w/ writing up an extension based on the shared guidelines [1]?





To unsubscribe from this group and stop receiving emails from it, send an email to collectionjson+unsubscribe@googlegroups.com.

John Leedham

unread,
Apr 25, 2017, 8:30:26 AM4/25/17
to collect...@googlegroups.com
Hi Mike,

I've drafted up something based on our discussion - pull request has been sent (please forgive any errors - don't normally write either mark-down or technical documentation)

Thanks,

John
--

John Leedham
Director
TWANG MEDIA CONSULTING
Telephone: +44 (0)1293 735065


mca

unread,
Apr 29, 2017, 1:12:07 PM4/29/17
to collect...@googlegroups.com
John:

I've merged in the extension. 

I'd like to suggest we say the "properties" element is an array of "data" objects. I think this covers the fields you mention and simplifies the parsing of messages -- no new objects/properties to deal with. It also sets up the ability to extend properties the same way you can extend data objects.

Do you see any drawbacks to this idea?




John Leedham

unread,
May 3, 2017, 6:01:11 AM5/3/17
to Collection+JSON
Hi Mike,

Yes, that's how in envisaged it. I'm very happy for you to amend the text in line with what you say. 

The reason I didn't describe it as an array of "data" object's is that I wasn't clear that a "data object" was a defined 'thing'. 

So I lifted the text from the data property verbatim instead, ergo the 'anonymous object'. 

On reflection, "data object" is probably sufficiently implicitly defined via the "data" property that it can be used!

John
--

John Leedham


Director
TWANG MEDIA CONSULTING
Telephone: +44 (0)1293 735065

--
You received this message because you are subscribed to the Google Groups "Collection+JSON" group.

mca

unread,
May 3, 2017, 11:57:06 AM5/3/17
to collect...@googlegroups.com
cool.

i'll review it this weekend and we should be good to go.

anyone else have feedback on this extension?

thanks.



To unsubscribe from this group and stop receiving emails from it, send an email to collectionjson+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages