Сергей Тихонов

users_mat = json.load(f)
print (str(json.load(f)))

Прочитали файл до конца, распарсили, а потом пытаетесь распечатать результат парсинга конца файла.

1. File/ImageField отлично подходят, только стоит учитывать, что они открывают файл на чтение для валидации при каждом сохранении объекта черед админку. И да, они хранят сылку на сервере (точнее относительный путь в какой-то ФС). Storage backend позволяет вместо локального диска использовать что-то более надежное, распределенное и масштабируемое чем локальный диск на единственном сервере.
   
2. Для фото еще куда ни шло, но передавать видео в любом виде, отличном от application/octet-stream - это трата ресурсов, как браузера пользователя, так и сервера. Соответственно, в JSONResponse только ссылки.
   
3. Хранить файлы на сервере по-другому не получится, не в MongoDB же их пихать. Не очень понятно, что конкретно смущает в приведенной ссылке на 1.avi
   
4. В nix-ах есть особенность реализации ФС: любой каталог, в котором 10к+ файлов, размывает кэш дескрипторов ФС, поэтому при хранении БОЛЬШОГО числа файлов их раскладывают по двух-трех-уровневой иерархии каталогов. См. FileField.upload_to для примера, как это можно интегрировать в Django. А так в целом да, желательно чтобы по полному пути файла можно было определить, к какому объекту он относится, без использования БД (чтобы висячие файлы чистить)
   
   

Прикольная тема )
Основы языка запросов говорят, что значения после префикса wd: соответствуют объектам википедии (вот ваша сущность "страна"), а значения после префикса wtd: соответствуют свойству (что-то вроде "типа отношения": "является объектом класса")
Список свойств

Списка сущностей существовать не может (это оглавление всей wikidata), но внутренний поиск нужные идентификаторы возваращает

>>> import json
>>> a = {"trainings": [{"more": "dicts"}, {"and": "even_more"}]}
>>> json.dumps(a)
'{"trainings": [{"more": "dicts"}, {"and": "even_more"}]}'
>>>