- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Wed, 2 Jul 2014 11:52:48 +0200
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- Cc: public-linked-data-fragments@w3.org
Hi Markus, >>> 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. Wah, not necessarily an "optimization", perhaps just a very use-case-specific solution. > 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. …which is why I think “features” are better to support. >> 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? I understood it as: you request “2013", the server adds links in the representation to "January 2013, February 2013, etc.”. One could argue that the hypermedia controls to request "any" range would already be there. True, but the links can still be very useful for different types of clients. > 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. Terminology correction: the result of a SPARQL query *is* a Linked Data Fragment by definition [1]. However, the broader goal of Linked Data Fragments is indeed to define types of fragments that are *not* as complex to create as results to SPARQL queries. Triple Pattern Fragments ("basic" Linked Data Fragments) are such a type [2]. >>> 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). True; however, is the server is willing to support more complex date selectors, clients could take advantage of this and greatly reduce the number of requests, leading to a strong performance boost for such queries. This would be a very strong mechanism to support; and can be nicely done with Hydra hypermedia controls. > Full text search is, IMO, a different beast altogether and should be treated as such. Partly true, but again servers could indicate what they support, e.g.: - “you can search for triples with an object that contains a term” - “you can search for triples with an object that starts with a term” - “you can search for triples with an object that matches a regular expression” - “you can search for triples with an object that fuzzy matches a term” Depending on how far the server is willing to go, clients could do a lot of interesting stuff with that. All dynamically discoverable. BTW All of this should *not* be part of Triple Pattern Fragments; which should remain the most basic thing a server supports. Rather, they are optional opt-in features a server can offer and dynamically advertise to clients. > 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. True, but if a server wants to offer it, why not? Best, Ruben [1] http://www.hydra-cg.com/spec/latest/linked-data-fragments/#sparql-query-results [2] http://www.hydra-cg.com/spec/latest/linked-data-fragments/#triple-pattern-fragments
Received on Wednesday, 2 July 2014 09:53:21 UTC