{"id":1692,"date":"2009-04-22T16:52:00","date_gmt":"2009-04-22T16:52:00","guid":{"rendered":"http:\/\/www.leobard.net\/blog\/?p=1692"},"modified":"2017-11-04T15:51:00","modified_gmt":"2017-11-04T15:51:00","slug":"annotating-files-but-where-to-store-the-metadata","status":"publish","type":"post","link":"https:\/\/www.leobard.net\/blog\/2009\/04\/22\/annotating-files-but-where-to-store-the-metadata\/","title":{"rendered":"Annotating files – but where to store the metadata?"},"content":{"rendered":"

An interesting thread about file metadata for KDE got my attention: Portable Meta-Information<\/a>. I waited a month until it cooled down and re-read it to draw my own conclusions.<\/p>\n

The author, zwabel, correclty identified the problem that the Semantic Desktop must be compatible with the past – and with the future!<\/b>.<\/p>\n

I think, for the future, we need to find a way to keep the users data together, so it is as persistent and approachable as the files themselves:
\n– When the user copies his photo archive or backs it up to a CD, no matter what application he uses, meta-information like ratings, comments, or tags, have to move together with the photos
\n– When the user has a fresh install, and copies his photo archive from a CD to the disk, the meta-information for the photos should be just there
\n– User-generated meta-data should _never_ be lost just because a file\/directory was renamed, a mount-point changed, or whatever
\n– User-generated meta-data should not be lost when a file completely unrelated to the item is damaged or deleted(Database)
\n– In 20 years, when KDE4 is history for a long time, and I find an old photo backup CD, the meta-data should still be readable<\/cite><\/p>\n

zwabel then suggested to store the metadata additionally to the central store (which NEPOMUK needs for the search engine and is essential anyway) in a multitude of “.meta” files, which are stored in the same directory as the files. For the file picture1.png, the metadata would be in picture1.png.meta. I think this is a pragmatic idea and would say:<\/p>\n

Lets store it in picture1.png.rdf<\/b><\/p>\n

As serialization, I suggest the W3C RDF standard, which we use in the central NEPOMUK store anyway (in the database) and which has a well-readable standardized serialization format in either XML or a plain-text format. To achieve linux-geek compability, I suggest the plaintext format. For example, to add authorship information about picture1.png, it would be:<\/p>\n

\n@prefix dc: <http:\/\/purl.org\/dc\/elements\/1.1\/>.\n@prefix rdf: <http:\/\/www.w3.org\/1999\/02\/22-rdf-syntax-ns#>.  \n<>  dc:creator \"Dave Beckett\";\ndc:date \"2002-07-31\";\ndc:publisher \"ILRT, University of Bristol\";\ndc:title \"Dave Beckett's Home Page\" .\n<\/pre>\n
Note that the <> is a known shortcut for “this”, the equivalent rdf\/xml is: rdf:about=””.<\/p>\n
Sebastian Tr\u00fcg also argues in a way that also leaves both ways open for the future, database and filesystem:
\n“you need a database anyway. Thus, in the end, the only solution I see at the moment is a kind of copy wrapper that makes sure metadata is copied with the file. Then one could also send information like a person or a project to a friend and the system would pick up all interesting metadata.”<\/cite><\/p>\n
So – how do we format the metadata inside the files? The same way we do as in the RDF repository of nepomuk. There we use the NIE<\/a> and NAO<\/a> ontologies. But Pushing Dublin Core is also a good way to do, but do it the W3C way, standardized. <\/p>\n
Using the RDF encoding of Dublin Core and for example Turtle\/N3 as serialization format gives a rock-solid W3C industry standardized (or at least well implemented) way. <\/p>\n
Because the world is not perfect and needs many possible ways to evolve, we can store the metadata in redundancy now in as many places as possible – but in one format. For freedesktop and nepomuk RDF is the best choice, in my (not so humble) opinion. It is serializeable, it can be stored in a database, it can be hosted on the web. No other standard has this. It is embedded in PDF already in the XMPP format.<\/p>\n
I propose “.turtle” files to indicate that its RDF\/Turtle serialization, but if you insist, “.rdf” is also fine with me (but implying RDF\/XML storage, which is a bit sluggish), and “.meta” is also fine with me if you store RDF\/turtle inside. Making up a new micro format would be stupid.<\/p>\n
My Summary:<\/p>\n