W3C home > Mailing lists > Public > public-hydra@w3.org > July 2014

RE: ISSUE-56: Date ranges / intervals for LDF

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Wed, 2 Jul 2014 11:20:02 +0200
To: <public-linked-data-fragments@w3.org>
Message-ID: <0aa601cf95d6$ce958880$6bc09980$@gmx.net>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:42 UTC