Imagine you are a robot and I send you these bits of information:

```

{"accessed": "2020-06-06T10:18:14.384-00:00"}

```

As a robot, you do not know this is a date because no one told you how

"2020-06-06T10:18:14.384-00:00" is any different from "I like sandwiches"

Imagine you are still a robot and I send you this

```

{"client": "35151dcf-78bb-4830-a050-3425a8ee6df1"}

```

Again as a robot, you do not know what this means

Now imagine I send you this

```

{:client #uuid"35151dcf-78bb-4830-a050-3425a8ee6df1"

:accessed #inst"2020-06-06T10:18:14.384-00:00"}

```

The `#uuid` and `#inst` tags & the EDN format, tell you as a robot how to understand these messages, they are UUIDs and dates if we come to an agreement beforehand we can add our own tags for anything like `#toys` these are just some of the inbuilt ones (extensible data notation - EDN)

Now that's cool we can communicate types of things but what about sending SQL queries? Before we execute SQL queries we must know what things are values and what things are names like columns and tables, because we need to escape values to prevent SQL injection, in EDN we can communicate the difference between values and names with keywords:

```

{:select [:person.id :person.name]

:from [[:users :person]]

:where [:= :person.id 12345]}

```

In JSON we need to make up some non-standard solution with strings or worse yet serialize our language across the wire which stops others playing with us nicely because JSON doesn't give us what we need to differentiate between names and values

JSON is too simple and makes people who talk together with it work harder and talk together out of band because somethings cannot be expressed in it, EDN messages lets us understand and be understood better than JSON messages