Date ranges / intervals for LDF

[akuckartz]

Define a LDF for date ranges so that for example the objects of all the tripels are date values which are in the date interval.

[RubenVerborgh]

Thanks for reporting, @akuckartz. We definitely plan more specific types of Linked Data Fragments in addition to the Triple Pattern Fragments we have now.

That said, date ranges might be overly specific for an immediate next step. We would probably look first to support more generic literal value searches, such as full text search and pattern matching.

And interestingly, date ranges can be implemented in an easy way using pattern matching. For instance, the date range 2014-03-30 – 2014-04-22 could be implemented by two consecutive lookups of 2014-03-3X and 2014-04-XX—or perhaps even as one lookup 2014-0X-XX. To be investigated.

[akuckartz]

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)
2012-12
2013 (whole year)
2014-01
...
2014-04
2014-05-01
...
2014-05-22

That splitting could be done by the client.

[lanthaler]

Andreas, if you want feedback/replies to your comments, please post also to the mailing list. Only very few people do get notified when you comment on GitHub issues. That being said, I like the idea.

[RubenVerborgh]

From http://lists.w3.org/Archives/Public/public-hydra/2014Jul/0003.html:

That seems like a very good idea indeed, and it brings us to something broader.

There's essentially two things that we could do:

1. Define a new Linked Data Fragments type,
   which allows to select objects of type date by day/month/year.
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-text 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

[lanthaler]

Use case by Andreas Kuckartz:

A user is interested in text documents which were published within a certain time interval / date range and which contain a string of text (or something similar to that string) or where meta data contains this string. In other words: the user interface would be a form consisting of three fields: one for the start date, one for the end date and one for a search string.

[akuckartz]

Any news on this? (will post to mailing list when I see no reply here :-)

[RubenVerborgh]

No public news yet; we are currently researching this in our lab. Stay tuned; if we find something viable, it will eventually be published.

[akuckartz]

This seems to be a published result:
http://linkeddatafragments.org/publications/iswc2015-substring.pdf

Thanks :-)

[RubenVerborgh]

@akuckartz, well, part of it at least 😄 Full range support is still on its way, and we'll track progress here.

[rubensworks]

@akuckartz We are currently working on a model for such ranges: http://ceur-ws.org/Vol-1666/paper-03.pdf
An implementation inside TPF is still a WIP.

[akuckartz]

@rubensworks Thanks, I have just started reading the paper "Multidimensional Interfaces
for Selecting Data within Ordinal Ranges" and perhaps will use hypothes.is to provide comments: https://via.hypothes.is/http://ceur-ws.org/Vol-1666/paper-03.pdf

[asbjornu]

I might be misunderstanding what this discussion is about, but seeing how specific date range formats are being hashed out, isn't ISO 8601 Intervals something that should be strongly considered?

[RubenVerborgh]

ISO 8601 is a syntax; this discussion is about a scalable mechanism to retrieve data within a certain interval (regardless of syntax, but SPARQL filters are a common case).

[alien-mcl]

This seems to be out of hydra scope - I'm closing it.

[RubenVerborgh]

@alien-mcl It's important to note that the LDF and Hydra efforts were joined. The LDF and TPF specifications are hosted under the Hydra namespace. Note the LDF tag on this issue.

I'm open to splitting off LDF from Hydra (for instance), but until that happens, LDF is under Hydra scope. So in that light, I'd like to request this issue be reopened.

[asbjornu]

While I don't mind LDF being hosted and managed by the HydraCG, it just leads to confusion to have two separate initiatives and specifications managed under the same repository on GitHub. I would vote for the creation of one or two new repositories underneath the @HydraCG organization and move the LDF and TPF related issues to them.

[akuckartz]

As the creator of this issue I am still interested in it.

[alien-mcl]

Due to demands of our community members, I'm reopening it. Still, I'd like to hear some possibilities to resolve this issue.
Personally, I'd go with IriTemplate that would allow client to provide same parameter multiple times, i.g.:
http://some.url/api/events?dateFrom=2018-01-01&dateTo=2018-01-10&dateFrom=2019-01-01&dateTo=2019-01-10&day=2019-02-01
Unfortunately, logic on how the server will interprete these is hidden:

• 2018-01-01 - 2018-01-10 and 2019-01-01 - 2019-01-10 and 2019-02-01
• 2018-01-01 - 2019-01-10 and 2019-02-10 (only min-max are taken into account)
• 2019-02-10 (specific day takes precedence)
• and so on...

[akuckartz]

@alien-mcl Proposals compatible with LDF concepts were made in previous comments.

[tpluscode]

@akuckartz is there anything missing in Hydra vocabulary? Or is the discussion within the scope of LDF?

[akuckartz]

This first of all is an LDF issue.