- From: Andreas Kuckartz <a.kuckartz@ping.de>
- Date: 2 Jul 2014 10:17:26 +0200
- To: "Ruben Verborgh" <ruben.verborgh@ugent.be>
- Cc: public-linked-data-fragments@w3.org
Hi Ruben, >> One approach I have had in mind would split a date range 2012-03-30 – 2014-05-22 into several segments which can be cached: >> 2012-10-30 (whole day) >> 2012-10-31 >> 2012-11 (whole month) > > That seems like a very good idea indeed, and it brings us to something broader. > > There'e essentially two things that we could do: > 1) Define a new Linked Data Fragments type [1], > which allows to select objects of type date by day/month/year. Extending the segmenting idea a bit: One single request from a client for the whole date range could lead to a reply from a server containing pointers to the segments. Obviously there are several performance questions which would have to be evaluated (requesting 25 segments within one month might not make sense when there are only very few items for those days, but matters will be different when huge numbers of items are involved.) > 2) Define something like LDF features or traits. > i.e., define "support for granular date selection" as a feature, > and an LDF server dynamically indicates (with hypermedia controls) > that it supports date-based selection. > > Option 2) has a lot of potential in my view, > because then a server can combine different features/traits, > such as full-tex search and date search. > > However, it is also the option that involves most work to implement: > - a way to describe features > - a way for clients to discover and use those features Working on 1) and full text search should be able to help illuminating what is necessary for 2). Both are major use cases and the use case I have in mind would regularly involve combining both. Cheers, Andreas
Received on Wednesday, 2 July 2014 08:19:28 UTC