Those fake mimetypes are installed by kdelibs with the file
/usr/share/mime/packages/kde.xml since long time ago. They are kept in
kde4libs.

In a recent version, update-mime-database became verbose about this unknown
types, and that is why you get this error when you update stuff and then
update-mime-database is run.
It is unlikely to be changed.

It appears that there are a pile of KDE libraries that bring in these otherwise Gnome unfriendly mime-type definitions. In my case, the libraries were added as dependencies to a KDE application package that I later uninstalled.

To remove the pile of KDE libraries and their associated /usr/share/mime entries, I used:

Do be careful that the first command does not force removal of a package you need before you confirm the removal. Getting rid of kdelibs-bin will then make a large set of packages unneeded and ready for autoremove.

That's a problem with update-mime-database and the MIME standard itself. Originally it was supposed to be extensible. But the IETF dumbed it down, and no new major mime types are registered (application/* is used as undifferentiated catch-all). The reasoning/surmise behind that being, that few tools are designed to work correctly with new MIME types.

Now update-mime-database at least doesn't fall over when it sees pseudo classifiers like uri/ and fonts/ or interface/. So I assume it only complains because other apps might actually trip over them. strings gave me following list of probably built-in list of "safe" MIME types:

text

application

image

audio

inode

video

message

model

multipart

x-content

x-epoc

Meaning it would nag over any other x- or x. and vnd. or prs. major mime types. Curiously inode/ is anything but an official media type.