Content on the web can be both beneficial as well as interesting however what do we do when we’d like to traverse the web to a certain time? It’s not an assuring answer when you can either download a dump of the internet or wait for a DDoS to subside. In LSD, time-based filtering is applied at the query level rather than column level.
If you’re less interested in how to grok time on LSD and more in the how-to of usage, skip on to the syntax otherwise this section’ll present how we set up the internet similar to spacetime.
Folks who sit on the concept of time during an idle afternoon or folks researching in the space can both attest to time being difficult to define which is why, in similar vein to SQL without ontology, we approach time as being a sort of measure rather than strictly a fixed dimension onto which data is coalesced.
For its physics complement, time filtering being applied at the query level is similar to how, in relativity, time is inseparable from and defined to be embedded with the space of interest. While we have yet to analytically extend the web into a differentiable function but we are accumulating the relevant data points to accomplish this which we believe unlocks a new frontier for how agents and AI alike can interop with the web as a whole.
On LSD, time is understood as two dimensions in the 4-manifold of the time-aware internet with two dimensions reflecting “space” to represent a particular point on the web:
▲
│
│
│
│
│
│
│
CLICK then ENTER │
│
│
ENTER │
│
│
CLICK │
│
┴──────────────────────────────────────────────►
google.com news.ycombinator.com
And two dimensions to define the “time surface area” within which you are interested in querying within: The time of interest being the point of time you’re interested in content near as well as the radius of the time surface area you’re interested in.
WITH TIME <time of interest> WITHIN <radius> MINUTES
radius
◄───|────────────────────────┼────────────────────────┼────────────►
time of interest
Assuming you’re starting with an expression written with pipe operator syntax, the syntax is as follows for an expression to denote the content you’re querying for as belonging to a particular time.
To convey you’re interested in content that existed before a particular Unix timestamp, declare that you’re interested in querying with the time of page being BEFORE a timestamp representing the number of seconds since epoch.
|> WITH TIME BEFORE <unix>
To convey you’re interested in content that existed after a particular point in time, declare that you’re interested in querying with the time of page being AFTER a timestamp representing the number of seconds since epoch.
|> WITH TIME AFTER <unix>
To convey you’re interested in content that existed around a particular point in time within certain boundaries, declare that you’re interested in querying with the time of page being AROUND a timestamp WITHIN respective bounds.
Note: Explicit boundaries are required when querying for a time AROUND a given timestamp.
|> WITH TIME AROUND <unix> WITHIN <num> <boundaries>
Boundaries can be specify a search area to be WITHIN a certain range from a particular point in time. This can establish limits to the time surface area you’re looking within whether that’s BEFORE or AFTER a point in time or how far AROUND a point in time. The available units are SECONDS
:
|> WITH TIME BEFORE <unix> WITHIN 60 SECONDS
MINUTES
:
|> WITH TIME BEFORE <unix> WITHIN 10 MINUTES
HOURS
:
|> WITH TIME AFTER <unix> WITHIN 6 HOURS
DAYS
:
|> WITH TIME AROUND <unix> WITHIN 4 DAYS
And WEEKS
:
|> WITH TIME AROUND <unix> WITHIN 2 WEEKS
Here’s what a query looks like to query for the front page of Hacker News when the world was about to end in 2012:
hn <| https://news.ycombinator.com |
container <| span.titleline |
post <| a |
FROM hn
|> GROUP BY container
|> SELECT post, post@href AS post_link
|> WITH TIME AROUND 1356066000 WITHIN 12 HOURS