Submitted by “PC users have volumes of information saved on their computers, most of it disconnected and disparate save for a basic directory system. The answer to connecting all the information into a local semantic Web of information is closer than you might think. Thanks to the open source NEPOMUK (Networked Environment for Personalized, Ontology-based Management of Unified Knowledge) effort, the Semantic Desktop isn’t a dream; it’s an emerging reality and will be here with the upcoming release of KDE 4 for the Linux desktop.”
Open Source Semantic Desktop Is Coming
50 Comments
2007-07-15 12:32 am
2007-07-14 9:03 pm
2007-07-14 9:03 pm
-
2007-07-14 9:28 pm
ronaldstfor microsoft’s ‘extended’ NEPOMUK….
Why would they need to extend something they already been offering for a while? Microsoft’s stuff is already industry standard.
2007-07-15 7:23 am
-
2007-07-16 2:08 am
-
2007-07-15 7:39 am
-
2007-07-15 1:05 pm
-
2007-07-15 4:34 pm
-
-
2007-07-16 5:45 am
2007-07-15 9:12 am
2007-07-15 3:38 pm
-
2007-07-15 8:38 pm
2007-07-15 10:53 pm
2007-07-16 2:39 pm
…towards a semantic web, if I understand the article correctly. Apparently it’s supported by the European Union as well.
What I find especially interesting is that the NEPOMUK specs, as truly open specs, are being implemented for GNOME and Windows. It’s nice to think that, if this turns out half way as good as it sounds, nobody will have to be left out.
From the very first mention of spotlight, I have been waiting for people using DB file systems to actually start innovating on the same tired ideas we have been using for years now. At first, I was sure Apple would give it to us, as they tend to lead the way in such things. Instead, we have just gotten better and better searches with spotlight. Then MS starts talking about all the cool new things they will do with it, and I thought “Man, what a slap in the face for apple, to be beaten to the punch for once by MS”. Instead, we got something that is significantly WORSE then spotlight. Then beagle gets announced, I try it out, and it seems like a simple “Me Too” type of technology that will forever be a few generations behind the other two.
Fast forward a few years, and its Linux who is leading the way. I honestly didn’t think it would happen, but we are seeing far more progress on this front with NEPOMUK then with anything else. I still cant wait for the day when folders are no longer used in place of metadata, allowing for fairly flat filesystems, and file names are only one of many identifiers for what you are looking for, but at this point any step in that direction is reason for celebration.
I’m pretty much in agreement with that. During Vista development, I was really put off by Microsoft dropping meta data for everything but Office files. Losing WinFS and then any semblance of meta cut the heart out of the new Explorer. Now Apple may have delivered detailed meta searching (and decent saved searches), but there is still no up front way of tagging and editing meta on the filesystem, and this is where NEPOMUK is stepping up the game.
My only real concern is that It’s going to be near impossible to breakdown the desktop/folder metaphor that everybody is so used to, and go fully meta.
I think it would be fairly easy to emulate folders using a metadata-based system. For the end user everything could look as usual, while under the hood a folder is implemented as a query for files with some specific attributes.
> It’s going to be near impossible to breakdown
these sorts of changes will inevitably be multi-generational. but they need to start at some point, right? =) we shouldn’t be discouraged if we don’t get to the final destination with the first iteration. we should only be discouraged if we aren’t moving towards that destination as quickly as possible.
there are several things in kde4 that are like this, btw.
Application developers can give the notion of semantic organization a kick-start by guiding users toward contributing metadata. For example, a media player could offer to add a common tag to files in a playlist. The “Save As” dialog for any application would be an obvious place to “remind” the user to add tags (maybe this done already).
Also, I think it might be useful to introduce generic key/value pairs to the possible metadata types. MIME types could be associated with default keys, and multiple applications could use well-known keys to communicate through metadata without requiring action from the user.
There may be some potential worries about malicious applications doing bad things with metadata, but I’m not sure there’s any way to prevent that even in the current design. Maybe applications should be allowed to create private keys that no other application can modify. This would be a convenient way for applications to save per-file state.
Just some ideas. Keep up the good work!
> useful to introduce generic key/value pairs to the
> possible metadata types
from the pure metadata POV work on standardizing this is being done already (and common sense has already brought us a long ways there) and from the RDF side we have shared ontologies.
The thing is people already use folders and file names for this purpose. You have pictures/family/vacation/2001/franksallybeach22.jpg. Instead, it could be /personal/nice day.jpg tagged with family, vacation, vacation 2001, frank, sally, beach. Using folders for this purpose, you end up with extraordinarily long mazes with your information at the end, with very little flexibility in navigation. Using a meta approach is such a jump forward in every way, i really think people would jump on it, even though it is quite different.
I mean, look at flickr, facebook, gmail, digg, etc. People get tagging, they love tagging, and they use tagging. The technology is here for operating systems, and it boggles my mind that neither Apple or MS is moving forward with this.
Hmm. I personally don’t add tags to anything at all. It’s just so much easier and faster to give files a proper filename and save them in a logical place. I’d be annoyed a bit if I had to f.ex. specify tags for a file when saving it. Oh well, I guess this is just not my thing.
Manual tagging is just one of the sources envisioned here.
Manual tagging allows you to enhance meta data an relations by information that is closer to your way of thinking, thus allowing you to take this personal information into account when searching.
But semantic information can also be derived automatically, by the software handling your data.
The article offers the example of relating a file to the email it was saved from. Such an information can be added by the email program automatically on save.
Together with the also automatically derivable information about the email’s sender (e.g. by indexing the emails), you can then search for the file by just knowing who sent it.
Proper integration into applications will ensure that (less) information is lost during operations.
Manual tagging can be used to add information not available to any of the involved applications, especially subjective values like “uhh, pretty!”
I just started thinking about something..If you f.ex. save a file from an email, and the saved file automatically acquires metadata such as the sender’s email address, couldn’t this be considered potentially a threat if there’s several users on the same computer? If the file’s metadata is readable by other users and they have read-access to even some of your files, they could learn email addresses of the people you stay in contact with etc. In that case it’d help if the metadata was accessible only by the owner of the file, but what if sooner or later f.ex. system files are populated with metadata? The only way I can think of how to fix that would be to have two kinds of metadata: private and public.
metadata currently is private to the user. sharing/merging metadata will be a by permission thing only, and we’re still a couple years away from that anyways.
Aaron already answered this, but just a bit more detailed: the acquired relation data is stored in an relation database separate from the file. Thus the file itself remains “clean”.
For some kind of data it might make sense to also store it in the file or in extended file system attributes. This is currently not implemented AFAIK and as Aaron pointed out, would be subject to policies.
For some kind of data it might make sense to also store it in the file or in extended file system attributes. This is currently not implemented AFAIK and as Aaron pointed out, would be subject to policies.
IMHO all such metadata information should be stored per-file, ie. in extended attributes cos then it could be shared by all users. And I don’t really like the idea of a single database with all the metadata cos it could get corrupted, or if it got deleted one way or another you’d lose ALL metadata. But to have public and private metadata saved per-file would most likely require modifications to existing filesystems, or a completely new one. Hopefully this will happen, I’m sure a lot of people would find such a thing useful even if I can’t imagine myself gaining much from that.
I agree. The problem this addresses is easily seen on current systems. On XP, if I save information such as keywords, subject, category for some file formats, the information is lost when I copy the file to my keydrive. PDF docs are one common example. If I dl a white paper at work and wish to transfer it home, I can count on reentering the info at a later date. With jpegs, that information can be written to ITPC and MP3s can store the info in ID3 tags.
The bonus to having an index is that it speeds local searching and that attributes can be entered on a per-user basis. It supports things like shared music off a file server. I can rate a song 5 stars and my wife rate it 3 stars. If it were per file, she would overwrite my rating.
The problem isn’t the file system per se. Most any file system can have filters added for extended attributes. The problem is in file formats. Some support them, some don’t and some are implemented poorly (PDF).
The problem isn’t the file system per se. Most any file system can have filters added for extended attributes. The problem is in file formats. Some support them, some don’t and some are implemented poorly (PDF).
Umm, it’s not the files themselves which should have support for extended attributes..That would require modifying _every_ single filetype that’s supposed to have any metadata at all. Not gonna happen. It’s the filesystem which should handle metadata, that way the filetype wouldn’t matter at all as metadata would be possible on any and every file.
Umm, it’s not the files themselves which should have support for extended attributes..That would require modifying _every_ single filetype that’s supposed to have any metadata at all. Not gonna happen. It’s the filesystem which should handle metadata, that way the filetype wouldn’t matter at all as metadata would be possible on any and every file.
What you say is perfectly correct, and file system level metadata would be good.
But the point of the semantic desktop is to use concepts from the semantic web such a RDF as a common meta data format, and held in a local triple store SPARQL end point that can be queried. Where the meta-data is held before it is extracted isn’t important, because adaptor code can be written to extract it from all the existing file formats.
The semantic desktop builds on concepts from the semantic web, and this paper (which I’m still trying to understand), describes how they differ:
http://protege.stanford.edu/conference/2007/presentations/12.04_Cai…
The NEPOMUK Representational Language will allow you to describe the links between multiple RDF vocabularies that you might have in your metadata. And so you would be able to combine, say FOAF data about people, with VCARD data about business contact addresses for specific useful purposes.
Well, speaking as someone who’s lost my ratings and scores on my files in Amarok several times now due to reinstalls, etc, I worry about relying on metadata cached elsewhere. I mean, in the long run, I still know which songs in my collection I like and don’t rely too heavily on Amarok’s rating system… but supposing we were, this metadata would have to be stored somewhere.
I think what we eventually need is a filesystem wherin each file consists of a file and a hidden folder (or maybe just a data block, with a maximum size, to prevent abuse) that can contain a flexible amount and type of metadata specific to the file. I think that’s what HFS+ and Reiser4 do, but that’s not how Linux is set up to work. Yet, anyway.
Somewhere in all of this, of course, what metadata is connected with each file will have to be automated, but by then we’ll need enough tags and categories that files can be properly categorized. My own music collection, again, is a mess. Genres don’t always line up, though occasionally I go through them and try to fix the capitalization or remove a confusing type… Is it pop or alternative? Soundtrack, or Classical?
Edited 2007-07-16 16:28
The only issue I could see in terms of a filesystem based meta system would be that it would make any such feature filesystem dependent and KDE prides itself in being system independent which is why you see abstractions of technology such as HAL. Otherwise this would seem a more robust way to go. There are pros and cons to having a less dictated software stack.
Uh? I isn’t stored at “/home/your_username/.amarok” ?
And besides, if you install your “/home” in a separate partition/disk you don’t loose any configuration after reinstalls.
One time, I completely wiped my computer so I could make a larger /home partition; another time it was my KDE configuration that was causing the problem, and I ended up wiping out everything EXCEPT $HOME/.kde/apps/amarok (or wherever) but somehow it still seems to have reset and removed things.
“IMHO all such metadata information should be stored per-file.”
Bingo! What we need is for filesystems to unilaterally adopt meta-attributes. We have that with EXT2/3 using xattr.
If a system wants to keep an image of those attributes in a database for fast searches, thats one thing. But if the metadata exists only in the database it will just be a mess.
Take GNOME’s emblems. It’s great that I can put a little image on a file to help with organization, but if I move that file to another folder manually, I loose the emblem, becuase the emblem is not tied directly to the file. So it sucks.
If fundamentals like this aren’t addresse, I have a feeling this NEPOMUK stuff will prove to be all hype.
“Then MS starts talking about all the cool new things they will do with it, and I thought “Man, what a slap in the face for apple, to be beaten to the punch for once by MS”
Actually, MS started talking about integrated search long before spotlight. This was one of the rationals behind the failed “WinFS” DB driven filesystem. Apple came out with spotlight to counter that, and they succeeded. MS couldn’t make it work, and had to drop it from Vista.
I wasn’t talking about search, I was talking about using relationships between data and metadata for new forms of organization over the traditional file/folder thing we have been using for decades.
“I wasn’t talking about search, I was talking about using relationships between data and metadata for new forms of organization over the traditional file/folder thing we have been using for decades.”
What do you think is the basis of spotlight and WinFS? Rich metadata on file and directory structures to enable these “new forms of organization” The point of WinFS was to base the filesystem on a SQL store, to allow those relationships to be defined.
I just wrote the NEPOMUK article on Wikipedia a few hours ago.
http://en.wikipedia.org/wiki/NEPOMUK_%28framework%29
http://en.wikipedia.org/wiki/NEPOMUK-KDE
Feel free to improve.
Since I use GNOME, does anybody have links that show that GNOME is discussing the use of nepomuk?
Also, what does this mean for beagle and tracker?
The Nepomuk group is involved in the freedesktop.org discussion to create a standard for metadata databases which would allow them to be interchangeable and would allow any compliant front-end to be used to search any database. this is the general direction most projects are looking to move in, they just need to sort out the framework.
> to create a standard for metadata databases
you are referring to xesam? if so, that has very little impact on the ability for apps to tap into the sort of framework nepomuk offers.
it’s a step in the right direction as it starts to bring some commonalities into the search space, but it’s the first step of many, many more.
of course … what could end up happening with xesam, is xesam is adopted and the strigi+nepomuk combo gets chosen by more and more users and so full text searches return information stored by nepomuk enabled apps.
however, for proper integration to occur in non-kde apps they need to be instrumented to be able to add to the metadata and traverse the rdf stores… there’s a lot of work there, but i hope it starts to happen.
does anybody have links that show that GNOME is discussing the use of nepomuk?
I don’t know how this is related to official Gnome and Beagle, but you already have Beagle++ http://beagle.kbs.uni-hannover.de/ an extensions to Beagle using NEPOMUK.
Edited 2007-07-14 23:17
The demostration is here:
http://www.youtube.com/watch?v=Ui4GDkcR7-U
Beagle++: “