Your note suggests two cases:
(1) querying an actual interval, i.e. when the start and end date are explicitly specified;
(2) querying a temporal expression, e.g. Renaissance. (Which in itself is two cases, see below.)
There has been little discussion of querying EDTF intervals so there is really nothing to point you to. There has been some discussion of temporal expressions. The problem with temporal expressions is that there is no recognized controlled vocabulary. (More below.)
Say you want to query events whose dates are between yearA and yearB. This is a fairly easy query even aside from EDTF. For example using SRU/CQL, there is a built-in relation 'within' where the search term is expressed as a space separated start and end date, thus:
dc.date within "1900 1999"
For better precision than dc.date can provide, say you have an index - xy.date - known to consist of ISO 8601 dates. There is a CQL term modifier 'iso8601', and you can express the following query
xy.date within/iso8901 "1900-01-01 1900-01-30"
And with little trouble we could define CQL indexes and relations for EDTF. So assuming an index known to consist of EDTF dates, and say we define a CQL relation 'withinEDTFInterval'
xy.date withinEDTFInterval "1900-01-01/1900-01-30"
I see two use cases:
(a) find events that occurred during the Renaissance.
(b) find resources associated with the Renaissance.
In any case this relies on the ability to express "Renaissance", that is, it assumes a controlled vocabulary of temporal terms, which might include the term 'Renaissance' and that there is a common understanding of its meaning.
For (a), let's say you are querying resources for those with date of creation during the Renaissance. Let's say we define a CQL relation 'withinPeriod' where the term is assumed to be a temporal expression. The query could look like:
xy.dateOfCreation withinPeriod Renaissance
For (b), say that a resource (e.g. description of a painting) includes metadata listing temporal expressions associated with the resource:
xy.temporal = Renaissance
But as I noted, there isn't any agreed-upon controlled vocabualry for temporal expressions. Discussion of this came to a halt when we realized that we had to acknowledge this.
If you see this sort of functionality as a requirement, and you would like to move it along I am happy to help in that effort.
> -----Original Message-----
> From: Discussion of the Developing Date/Time Standards
> [mailto:[log in to unmask]] On Behalf Of Cope, Aaron Straup
> Sent: Friday, February 22, 2013 7:14 PM
> To: [log in to unmask]
> Subject: [DATETIME] Hello and a question about search
> Hi all,
> This is Aaron from the Cooper-Hewitt [1,2].
> I've been lurking for a couple months, after discovering the work being
> done here, and just digesting the conversation. I wanted to briefly stick
> my head up and say hello and ask what if any discussion there's been about
> the ability to query ranges of dates in EDTF ? And specifically, how it is
> or would be implemented (at the brass tacks level).
> I ask because it's very much germane to the work we're doing around the
> collection  and eventual re-opening of the museum in 2014. Currently
> we've got a finite list of "periods"  without explicit dates associated
> with them and a variety of "display dates" associated with individual
> objects that I've been able to block out in to something that we can sorta-
> kinda use for doing date queries on the set of things. 
> One of the things I've been tossing around, since getting to the CH, is
> some way to boil (with an emphasis on the boil-iness of boiling) a date
> down to a number. Specifically something that can be stuck in a database
> and operated against without the need for (insert some library or other
> software that I don't have or can't run). Numbers are awesome because all
> computers support them!
> The slightly longer version was discussed a while back on the Historic
> OpenStreetMap mailing list:
> I realize that Julian dates might in fact be a better solution but one of
> the things I would like to avoid doing is shifting the meaning of "zero"
> (relative to time) yet again. Fixing 0 to the Unix Epoch might seem a bit
> arbitrary because it is but it has the advantage of playing nicely with the
> Anyway, it's all still wet paint in my mind so I'd curious to know what has
> been discussed about searching EDTF ranges or pointers to stuff I can read
> up on.
>  http://collection.cooperhewitt.org/periods/ <-- we will probably ask an
> intern to at least mark these up in EDTF soon, if nothing else