- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Wed, 2 Jul 2014 11:20:02 +0200
- To: <public-linked-data-fragments@w3.org>
On 2 Jul 2014 at 10:17, Andreas Kuckartz wrote: >>> 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) >> > On 2 Jul 2014 at 09:34, Ruben Verborgh wrote: >> 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. In my opinion that would be a premature optimization. Now, granted, dates lend themselves as they are widely used but then again basically the same argument could hold for a plethora of other datatypes. > 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. Hmm... so you are saying that the client asks the server "give me everything within this range" and the server replies "if you want that, go here, here, and there"? I'm not sure yet what to think about that. If the server gives the client enough information to know where to go in the first place, this seems a bit like overkill and if results grow too big they can always be paginated. But perhaps you had something else in mind? > 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.) Yeah. We have to keep in mind though that LDFs are *not* arbitrary SPARQL queries from the server's perspective. If we add too much granularity/variation, they loose all their appeal compared to SPARQL. >> 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. >> AFAICT, for the use case at hand, that's already supported by triple pattern fragments. You just need to split the range *on the client side* into multiple dates (e.g., 2014-07-01, 2014-07-02, ..., 2014-07-31) and query by object. What's missing is the implementation of this feature on the client side (and the complete specification of how to turn SPARQL queries into LDF requests). >> 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. Full text search is, IMO, a different beast altogether and should be treated as such. The whole premise that LDFs can be cheaply served as the limited number of LDFs per triple can be easily cached doesn't hold for full text queries. >> 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. Could you please tell us a bit more about your use cases so that we have something concrete to discuss? Cheers, Markus -- Markus Lanthaler @markuslanthaler
Received on Wednesday, 2 July 2014 09:20:31 UTC