Benjamin Geer

> Amongst the parameters that I bear in mind to design a data model, I have to say that I never thought about not overloading the triplestore. This is absolutely...

Just to put this in context: in the past 5 years, the Knora developers have spent a lot of time working on improving the performance of SPARQL queries, and on...

> I am still not convinced that technical limitations should drive and restrain the data model of a research project... Ask any experienced software developer who has worked on database...

> Is there a special reason for that? I would guess it’s because every CONSTRUCT result is a set of triples, and the members of a set are distinct by...

> The only solution I see is to provide a search textfield filling the combo box according to the textfield (imitating the Salsah way to link resources). But as usual,...

This sounds like an interesting use case that deserves some thought. In any case, though, I think `DISTINCT` isn’t what you want. In SPARQL, `DISTINCT` exists only for `SELECT` queries,...

After thinking about this some more, I think you have two problems here: 1. You want years, which are not actually stored in your resources. Gravsearch can't give you this,...

> if `year` was actually stored in the tripple store as is, gravsearch querries can traverse the graph so why would `year` be one step too far in the path...

Actually, even putting the year in the resource isn't going to give you a list of years, because Gravsearch will still return a list of resources. I guess you could...

I have an idea. If you made a `GregorianYear` class, with one instance per year (representing the first and last days of the year, using `YEAR` precision) and if we...