Slashdot: News for Nerds


Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

RDF For Desktop Metadata?

timothy posted about 10 years ago | from the lateral-migration dept.

GUI 167

claes writes "There is an article "Metadata for the desktop" that suggests that RDF should be used to describe data in desktop environments. This is an interesting idea. RDF is already used by Creative Commons to attach license metadata to its works. Mozilla also supports it. RDF was designed for the web, but can it also find its way to the desktop? And what metadata is most important to describe?"

cancel ×


The killer app for metadata on the desktop (5, Funny)

foidulus (743482) | about 10 years ago | (#9602784)

is porn!
Suppose today I want to see shaved asian hardcore action. Now provided that metadata searches are integrated into the OS(like they will be in Tiger), all I need to do is a quick metadata search on my hard drive and boom, there is what I am looking for.
I mean provided there was a decent standard(a porn standards body would rule!) and good regex capabilities built into the OS, I would be willing to pay for porn. I know that there are comments built into the jpeg standard, but there are all sorts of porn file formats, it would be helpful to have a universal standard across them. It saves time, beats trying to search on google and going through a lot of crap just to get to something good. I am a man on the run, I have places to go, I can't be bogged down by my porn. Plus, think of the people that get to catagorize this stuff(well, the fun stuff anyway, not goatse), what an awesome job that would be!
I should probably post AC, but I figure this post is bound to earn me at least one fan and/or freak.

Re:The killer app for metadata on the desktop (5, Funny)

PowerBook2k (312576) | about 10 years ago | (#9602816)

Suppose today I want to see shaved asian hardcore action.

Just check your email. If it's not there now, it will be soon enough.

Re:The killer app for metadata on the desktop (1)

lawpoop (604919) | about 10 years ago | (#9602834)

"... today I want to see shaved asian hardcore action."

Are you, perchance, a geek?

Re:The killer app for metadata on the desktop (1)

foidulus (743482) | about 10 years ago | (#9602847)

That obvious huh?
I guess even moreso in that I watch but, have yet to participate in it.
Geek squared!

Re:The killer app for metadata on the desktop (1)

scupper (687418) | about 10 years ago | (#9602901)

You speak for the "silent majority". Lead on!

Re:The killer app for metadata on the desktop (0)

Anonymous Coward | about 10 years ago | (#9603265)

I don't think that virgin, "shaved asian hardcore action" watching, slashdot subscribers are any kind of majority...

Calling Autopr0n! (2, Funny)

mrchaotica (681592) | about 10 years ago | (#9602936)

If ever there was an appropriate thread for him to post in, this is it! : D

Re:The killer app for metadata on the desktop (0)

Anonymous Coward | about 10 years ago | (#9603058)

"Suppose today I want to see shaved asian hardcore action."

Why do I get the feeling this isn't just "supposition"?

Re:The killer app for metadata on the desktop (1, Funny)

Anonymous Coward | about 10 years ago | (#9603084)

Awesome! I love it. I'd clap, but, uh... I can't right now...

Re:The killer app for metadata on the desktop (0)

Anonymous Coward | about 10 years ago | (#9603632)

I mean provided there was a decent standard(a porn standards body would rule!)

Have you ever actually been to a porn site? Nearly half of the metadata would be wrong or misleading. Your "shaved asian hardcore action" would give you a hairy fat lady in Nebraska fucking goats. Or, more likely, a list of links to sites listing links to sites that claim to have porn, but really are just an experiment in showing small flashing penises to geeks.

Me (-1, Offtopic)

Anonymous Coward | about 10 years ago | (#9602791)


Definition:...? (5, Interesting)

bogaboga (793279) | about 10 years ago | (#9602819)

Why don't slashdoters define what meta-data is in the first place? Google's define: metadata lists not less than 20 definitions. Are we talking about "data about data"?

Re:Definition:...? (3, Informative)

ResidntGeek (772730) | about 10 years ago | (#9602833)


Re:Definition:...? (2, Insightful)

doshell (757915) | about 10 years ago | (#9602900)

So, data describing metadata would be called metametadata?

Re:Definition:...? (3, Insightful)

Jugalator (259273) | about 10 years ago | (#9602922)

Yep, it's called like that.

I don't see with the thread started wanted a definition by Slashdotters in the first place, since it's already pretty well described [] and AFAIK the word doesn't have several meanings.

Re:Definition:...? (0, Offtopic)

Jugalator (259273) | about 10 years ago | (#9602931)

Wow, I'm typing like I'm drunk...

s/with the thread started/why the thread starter/

Re:Definition:...? (1)

ResidntGeek (772730) | about 10 years ago | (#9602961)

Oh, but there were 20 definitions in google's define:metadata, and that's just so much to read. Had he read it, he'd have noticed that 13 have the exact phrase "data about data", 3 say "information about data" instead, one says "information about a file", one says "data about the data", one says "data that describes something", and one says "Data that provides information about, or documentation of, other data". I wouldn't have modded it interesting.

Re:Definition:...? (3, Informative)

Anonymous Coward | about 10 years ago | (#9602905)

In short, Yes.

Say you have a digital photo. It's from a vacation you took in 2002, to hawaii, and contains photos of you, your partner, one of your children, but not your other kids and no pets. All that info could be kept as metadata of those pictures, and more.

The same can be done for finance info for the year 1999 for you, or 2001 for your partner, or music files bought from a certain place, by a certain artist and band.

While each of the filetypes above can have their own metadata (exif for images, comments for excel spreadsheets and mp3 tags for music) not all of it is singularly accessible and searchable by the one mechanism by the OS.

This is a good goal.

Re:Definition:...? (1)

0racle (667029) | about 10 years ago | (#9602968)

All those definitions say the same thing, so what was your problem?

Re:Definition:...? (2, Funny)

zephc (225327) | about 10 years ago | (#9602976)

I never Metadata [] I didn't like.

Re:Definition:...? (1)

Lehk228 (705449) | about 10 years ago | (#9602983)

it is file info, resolution, dimensions, bitrate, keywords, framerate, previous owners of the file, access history, what colors are most common in a picture, who is in a pic. basically any information about a file you may want to know to sort or find that file

You answered your own question (0)

Anonymous Coward | about 10 years ago | (#9603127)

There's no need to provide definitions for terms which are so easily looked up. Metadata isn't an obscure concept, as you found when you did your search.

Come on, mods... (0)

Anonymous Coward | about 10 years ago | (#9603171)

Interesting? The Voynich Manuscript is interesting. The Linux kernel is interesting. A guy who can't be bothered to read more than 3 words of 1 definition of a word isn't interesting. This post should be at -1, Troll. Might as well get a good mod on this post too: That and installing Gentoo on my home box.

Re:Come on, mods... (0)

Anonymous Coward | about 10 years ago | (#9603177)

And by "This post should be at -1, Troll", I meant the grandparent should be at -1, Troll. Oops.

An incomplete acronym (1)

mangu (126918) | about 10 years ago | (#9603214)

Read Da Fucking what?

Re:An incomplete acronym (0)

Anonymous Coward | about 10 years ago | (#9603642)

Just shut up and read it, n00b. We can't be bothered to tell you everything.

Implicit feedback for filesystem information (3, Informative)

PureFiction (10256) | about 10 years ago | (#9602841)

I am a big fan of implicit filesystem feedback [] . This can support all kinds of services from file sharing to most recently accessed search requests. Even fine tuning access controls in an RSBAC security policy.

The big concern is keeping this data protected and private. You dont want to share all of your metadata with everyone, so security of these systems should be something to look at carefully.

5th post! (0, Offtopic)

pingus (542585) | about 10 years ago | (#9602843)

yeah, this is retarded, meta me down.

What happened to forked files? (4, Insightful)

Amiga Lover (708890) | about 10 years ago | (#9602861)

Are there any filesystems left that use forked files? Resource, Data and Metadata forks? Any at all?

While MacOS was at a disadvantage being one of the only ones to use it, wouldn't it have been an excellent advantage for ALL filesystems to be forked?

(I don't know the answer to this - anyone who knows more about filesystems, give your thoughts)

Re:What happened to forked files? (1)

djcapelis (587616) | about 10 years ago | (#9602886)

I think NTFS actually has a similar stream feature where such things could be embedded. Reiser has a concept that everything should be a file, so you might as well hope for M$ to release a driver for Reiser than Reiser to do forks... not sure about ext.

NOTE: take this with a grain of salt, I know very little about filesystems.

Re:What happened to forked files? (1)

ResidntGeek (772730) | about 10 years ago | (#9602914)

According to, it's not happening in Linux filesystems.

Re:What happened to forked files? (4, Informative)

Jugalator (259273) | about 10 years ago | (#9602947)

Forks? Would that be the NTFS streams [] ?

I think the new filesystem WinFS in Longhorn is basically just an evolution of NTFS streams to make them more accessible for the users. They've always been there, just not very accessible besides a limited set of text fields in the file properties dialog box in Windows. (i.e. they've always been able to hold custom data and have custom key names)

Re:What happened to forked files? (1)

Shachaf (781326) | about 10 years ago | (#9603052)

WinFS is not a filesystem [] . It's "the active storage subsystem in "Longhorn" that is used for searching, organizing, and sharing data".

Re:What happened to forked files? (2, Informative)

k98sven (324383) | about 10 years ago | (#9603029)

While MacOS was at a disadvantage being one of the only ones to use it, wouldn't it have been an excellent advantage for ALL filesystems to be forked?

Well, one problem immediately springs to mind: The translation between different metadata formats. It's already a pain in the butt when using transferring files of not-so-popular types to the Mac.

The second gripe I have with the Mac is that it's so friggin' hard to edit the metadata. AFAIK you can't even do it on OS 9 without software. Now assuming the user is too stupid to change this manually is good. But not providing the ability at all, even for people who know what they're doing is just stupid.

(Windows first hides the extensions, then if you try to change them, it warns you first. That feels about right for me. - Not that extensions isn't a klugde.)

Apart from that, I agree.. anything is better than file extensions.

Re:What happened to forked files? (1)

sydtsai (318342) | about 10 years ago | (#9603145)

Spotlight []
Here is your solution.
It's pretty extensible so you can add-in the file formats that you wanna search.

Re:What happened to forked files? (3, Insightful)

Anonymous Coward | about 10 years ago | (#9603041)

> wouldn't it have been an excellent advantage
> for ALL filesystems to be forked?

Yes, but the trouble of compatibility remains. But there is a simple solution for this: fork as dir bundles: Instead of a file with a metadata fork you simply put the metadata file and the datafile into a dir and give that folder the name of the datafile. The current users copy the dir around and use its contents. But modern OSes treat the dir as if it is the datafile when the user interacts with it.

The metadata file says 'treat this dir as a file, when the user opens it please open the datafile called ... instead'

This is what Mac OS X does.

This has some cool advantages for the future of metadata because the metadata file can refere to multiple files inside the dir. Not just point out the datafile but also point out the Mac OS X icon (which is simply a tiff file) and even a custom kde icon. Yes you could have complete container documents like a webpage where individual objects can be individually for the knowledgeable user simply by opening the dir or access them as a whole.

It gets even better when you look at Applications in Mac OS X. Seemingly a file you can doubleclick to execute but actually a dir you can access with file organized in subdirs. Language dirs with UI files and text files you can translate, executables for different platforms, the required libs. It could even contain the source code yet it looks like, and by default works like, a single file which you can copy to the harddisk to install and drag to the trash to uninstall. That's how simple computing should be.

Re:What happened to forked files? (1)

mrchaotica (681592) | about 10 years ago | (#9603079)

The weird thing is, though, that Mac OS X has bundles and single-file resource forks. I understand using one or the other, but both?

Re:What happened to forked files? (1)

roshi (53475) | about 10 years ago | (#9603070)

A couple of things about this:

First off, the ability to use file type and other arbitrary metadata still exists in OSX (or HFS+, as the case may be). (More here [] .) This is above and beyond the much maligned resource fork.

The real issue both with resource forks and (to a lesser extent) filesystem level metadata is inter-system transport, ie how do you ftp the metadata along with the file. This is what made resource forks such a PITA.

Apple, it seems, has now moved away [] from putting the metadata in the FS, despite having the ability to do so, even as MS scrambles to stick metadata in their FS. I'm skeptical of the centralized DB approach, the FS approach seems a cleaner design, but the central DB does have the advantage of constantly pulling metadata out of the files and apps, thereby updating itself on the fly. Furthermore, in the separate DB approach, if the DB gets corrupted, you can trash and rebuild, if your FS gets corrupted.... that's a bigger headache. Time will tell which approach is better.

The author of the linked article seems to propose RDF as a solution, but I'm not convinced how well storing all that metadata as text in a "dot-file" will scale. And you still have the problem of getting that metadata from one system to another, despite having a common format.

One hopes that both Apple and MS can solve the problem of having their own systems cleanly exchange metadata.

Just some thoughts...

Re:What happened to forked files? (1)

hunterx11 (778171) | about 10 years ago | (#9603266)

You mean Apple will have to make its system exchange data with Windows which will use a system without the slightest thought to portability. I'm not trying to troll--this is less an issue of Apple believing in better code than it is a consequence of the fact that almost everybody uses Windows, so MS can afford to act like they are the only player, whereas Apple would be stupid to act the same.

In Soviet Russia (-1, Troll)

Anonymous Coward | about 10 years ago | (#9603104)

...the filesystem forks you.

Re:What happened to forked files? (1)

sploo22 (748838) | about 10 years ago | (#9603215)

I thought Ext2/3 supported "extended attributes", which are basically the same thing.

Re:What happened to forked files? (1)

The Vulture (248871) | about 10 years ago | (#9603427)

Going back someways, GEOS (on the Commodore 64 and 128, I don't know about other versions) had a version of this that they called VLIR (Variable Length Index Record) files.

A VLIR file would have one sector, and that one sector pointed to multiple other sectors. One of the sectors was used for the "information sector" (info on the file), and simple VLIR files would then have the data in one of the other pointers.

More complex applications, like geoWrite, would use one pointer per page of the document, this limiting you to a page/graphics count.

VLIR files were nice, but they caused problems for almost every non-GEOS program, since files were expected to be a series of raw bytes (sectors), not segments. Even in GEOS, I had problems with VLIR files, when writing applications (I tried writing a DeskTop replacement, eventually I succeeded with a geoWrite word counter Desk Accessory).

GEOS VLIR Information []

-- Joe

Integration (4, Interesting)

mrchaotica (681592) | about 10 years ago | (#9602896)

Why does the document complain about the lack of integration, then mention that Microsoft, Apple, the ReiserFS people, etc. are coming up with solutions, and then adds a completely new one? Shouldn't they just be supporting one Apple's or ReiserFS's efforts?

Re:Integration (1)

ResidntGeek (772730) | about 10 years ago | (#9603086)

Nah, that's how they tried to fix the Western Schism. Everyone started lining up on different sides, until they gave up, kicked all three popes out, and elected a new one.

What is wrong with you people? (2, Insightful)

Anonymous Coward | about 10 years ago | (#9602904)

Sure. I have no objection to a more extensive use of metadata. In fact I crave it - must have it.

But why oh why do people think that XML-based solutions is the way to go? An RDF solution would be bloat beyond belief. Ok, so it's not that bad for a few files, but when we get down to it - we don't have just a few files. We have plenty of them.

So why not use something smaler? A simpler protocol?
We can still have RDF-frontends for those that crave their daily XML-fix. Get real.

Re:What is wrong with you people? (1)

claes (25551) | about 10 years ago | (#9602959)

RDF does not equal XML. RDF is a way to express relationship through graphs. RDF/XML is one way to express these relationships, but there are other ways too. I thought that RDF always had to be expressed with XML too, but then I read the
RDF primer [] . At first I thought it was extremely overcomplicated, but after reading some more I started to grasp the concepts. And they are not about storage formats. They are about semantics.

Re:What is wrong with you people? (1)

jsled (11433) | about 10 years ago | (#9603515)

Yeah ... RDF is the simplest thing in the world. Subject+Property+Object ... Object is either another Subject, or a literal value.

And N3 [or Turtle] is a far better serialization than XML.

Semantics are important, but _agreement_ is even more so. The hope of RDF is that when we get away from the sillyness of XML and start agreeing about how to speak about relations [in terms of SPO], we can start talking about more interesting things like schema and semantics.

How much do you pay for HDD's (1)

oliverthered (187439) | about 10 years ago | (#9602975)

Last time I checked you can pick up HD storage space for $0.70 a GB.

I have 300,000 files on my Windows box (2, Informative)

MichaelCrawford (610140) | about 10 years ago | (#9603156)

I know this because ad-aware tells me so when I have it scan all my disks.

The vast majority are very small files. How much more space would be required to give each one some RDF? And remember disk space is allocate in terms of sectors, or sometimes in blocks of several sectors, so small files waste proportionately more space.

And that's just on the Windows installation for my PC. I also have Slackware Linux and BeOS on other partitions. Quite likely there are very nearly a million files on my PC alone.

This is largely irrelevant if you have experience (4, Insightful)

Real Troll Talk (793436) | about 10 years ago | (#9602935)

Since most of us are advanced computer users or even computer experts, I think we largely know how to search for content.

For one thing, I always give my filenames relevant titles, not things like document06.doc.

Also, I already know how to search through files for content using basic grep or advanced Windows searching.

I mean, sure, meta data like ID3 tags for MP3s that I steal offline are important because my Nomad mp3 player indexes based on that info, but in general I'd say meta data is not quite as important as some may suspect.

Re:This is largely irrelevant if you have experien (1)

k4_pacific (736911) | about 10 years ago | (#9603057)

Well, I have a file called DocumentNo5.mp3, but its a rip of an R.E.M. album.

FS support for metadata (5, Interesting)

doshell (757915) | about 10 years ago | (#9602948)

I've heard the NTFS file system is designed to allow the system to add any number of properties (besides the obvious filename, last access time and permissions) to any stored file. This is likely to be exploited by Longhorn, which is planned to be capable of appending metadata to newly created files (for example, if you download a file from the Internet, the system would likely append a Originated-From-URL property to it).

What I wonder is, is there any filesystem in the FOSS world that supports something like this, or are there plans to make it supported before 20??, when Longhorn hits the stores? I see this as a critical feature that must be made available by non-Windows OSes.

Re:FS support for metadata (2, Insightful)

PhrostyMcByte (589271) | about 10 years ago | (#9603009)

I don't think you can attach metadata to files with NTFS. If you can, I havn't seen the API for it anywhere while coding.

Longhorn is using WinFS, which afaik is just a metadata layer slapped on top of NTFS.

Re:FS support for metadata (1)

doshell (757915) | about 10 years ago | (#9603065)

Quoting from [] :

Each file on NTFS has a rather abstract constitution - it has no data, it has streams. One of the streams has the habitual for us sense - file data. But the majority of file attributes are also streams! Thus we have that the base file nature is only the number in MFT and the rest is optional. The given abstraction can be used for the creation of rather convenient things - for example it is possible to "stick" one more stream to a file, having recorded any data in it - for example information about the author and the file content as it was made in Windows 2000 (the most right bookmark in file properties which is accessible from the explorer).

Does this qualify as provision for metadata in the FS?

Re:FS support for metadata (1)

Tobias Luetke (707936) | about 10 years ago | (#9603072)

Longhorn is using WinFS, which afaik is just a metadata layer slapped on top of NTFS.

The storage engine for WinFS will come from the mssql team so thats hardly "slapped on top"

Re:FS support for metadata (1, Funny)

Anonymous Coward | about 10 years ago | (#9603108)

Yeah, it's more like dropping an aircraft carrier on top of a cow - there really isn't any way to describe it.

Re:FS support for metadata (5, Informative)

pizzarobot (633100) | about 10 years ago | (#9603200)

Actually, you can. To add a metadata item called "hidden.txt" to a file called picture.jpeg, just type on the command line:

notepad picture.jpeg:hidden.txt

Notepad should say that it "created the file." You should notice that no new files have been created: just look for them with explorer. But you can later open this "file" and read and edit it.

You can do this with any file with any metadata name.

Re:FS support for metadata (1)

Jeff DeMaagd (2015) | about 10 years ago | (#9603091)

I do know that NTFS supports "threads" or some such that there are alternate streams within a file. Alternate streams aren't called unless requested. There was a warning that a virus could hide itself within an alternate stream, such that a scanner wouldn't find it because they ignored the concept. Several years later there was an exploit made.

Streams don't look too hard to deal with, it was just an ignored feature, like Windows Scripting, no few paid attention until it was exploited with a virus.

Re:FS support for metadata (1)

fedux (262863) | about 10 years ago | (#9603262)

Do you mean this?:

Extended Attributes

Extended attributes are arbitrary name/value pairs which are associated with files or directories. They can be used to store system objects like capabilities of executables and access control lists, as well as user objects. The attr(5) manual page describes which kinds of extended attributes are defined.

Re:FS support for metadata (0)

Anonymous Coward | about 10 years ago | (#9603465)

Arbitrary name=value metadata for files is supported by several "FOSS" filesystems, including ext3fs, XFS, JFS and ReiserFS.

On Linux you need a relatively new kernel, and you need to read the documentation, the concept is called Extended Attributes (EAs). If popular it may eventually become the default behaviour, rather than an optional feature.

In the real world the usefulness of this feature depends on application software. Ordinary users don't manually tag metadata onto everything, even if goaded to do so. So the main source of metadata for such attributes will be applications. If your applications don't do anything useful with it, the feature itself is worthless.

let's keep the Meta data simple... (3, Insightful)

howman (170527) | about 10 years ago | (#9603006)

and possibly How...

Re:let's keep the Meta data simple... (0)

Anonymous Coward | about 10 years ago | (#9603093)

and Which.

Can I have my +1 Insightful now?

Re:let's keep the Meta data simple... (1)

jsled (11433) | about 10 years ago | (#9603478)

Yup, there's a vocabulary for that... []

Spotlight (2, Interesting)

Kesh (65890) | about 10 years ago | (#9603012)

I'm mostly wondering if the new Spotlight [] feature of MacOS X 10.4 is going to be based on this, or a proprietary technology. I've been itching for cross-platform metadata file support for years now...

Re:Spotlight (2, Informative)

aristotle-dude (626586) | about 10 years ago | (#9603060)

I don't see how considering that Spotlight is a search technology that leverages metadata already existing in files on OSX today and this article talks about tagging files with metadata.

The search technology in Spotlight probably is inspired by live query from BeOS but first appeared at Apple in iTunes and later Preview for Panther.

Many former Be Inc. employees work at Apple now and some had worked at Apple before joining Be.

Can't wait.. (2, Funny)

bigattichouse (527527) | about 10 years ago | (#9603051)

for when I can just throw out the whole desktop in favor of a "cloud" of data... using google-like interfaces to find my stuff. I think it would be interesting to figure out how to tell a compiler where to find stuff...

Re:Can't wait.. (1)

mrchaotica (681592) | about 10 years ago | (#9603120)

I've thought about using hard links (or maybe simlinks would do) to turn my file tree into a graph. I was particularly interested in sorting things like MP3s, where I could have all of them in one big /Music directory, but also have /Music/Artist/[ArtistName]/[MusicFile] and /Music/Genre/[GenreName]/[MusicFile] without actually duplicating the file. The only hard part would be writing tools to create the links automatically.

It would be good for doing things like grepping, but I wonder if a system-wide SQL database kind of thing would be better?

Re:Can't wait.. (1)

tono (38883) | about 10 years ago | (#9603154)

that's not a graph, it's a more detailed tree, and it's already arranged in a tree. I already arrange it by genre and then have itunes put it one big playlist.. there done.

Re:Can't wait.. (1)

mrchaotica (681592) | about 10 years ago | (#9603249)

I thought it was a graph because there was more than one path to the node (file), i.e. "/Music/Albuquerque.mp3", "/Music/Weird Al/Running With Scissors/Albuquerque.mp3", and "/Music/Pop/Albuquerque.mp3" were the exact same file.

Or as another example, for a "various artists" album you could have the songs available as /$Artist1/$Album/$Song1, /$Artist2/$Album/$Song2, /$Artist3/$Album/$Song3, etc., as well as /$Album/$Song1, 2, 3, etc. (in the same directory)

Re:Can't wait.. (1)

tono (38883) | about 10 years ago | (#9603353)

so it's a family tree that doesn't branch.. heheh. So let me get this straight, metadata takes data that already exists in the file, and makes it easy to search your files. So there's this whole big thing on making it easier to find your files on your harddrive that you put there?? Maybe we should consider a national spring clean your harddrive day..

Re:Can't wait.. (1)

mrchaotica (681592) | about 10 years ago | (#9603654)

Oh, I don't actually do that (I use iTunes now that I got a Mac; before then I just did mpg123 * and hit ctrl-c every time something came on I didn't like, and before that I just double-clicked mp3 files in Windows Explorer), I just thought it might be a neat idea.

Re:Can't wait.. (1)

pyrrhonist (701154) | about 10 years ago | (#9603403)

You were right. See here [] .

Re:Can't wait.. (1)

mrchaotica (681592) | about 10 years ago | (#9603681)

I know it; I learned that in CS 1321 : )

Re:Can't wait.. (1)

pyrrhonist (701154) | about 10 years ago | (#9603383)

that's not a graph, it's a more detailed tree, and it's already arranged in a tree.

Trees [] are graphs. A tree is a connected acyclic simple graph (i.e. any two vertices are connected by exactly one path).

What mrchaotica has done is add edges to the tree so that it has more than one path between some vertices. This makes the tree into just a graph.

Re:Can't wait.. (1)

EvanED (569694) | about 10 years ago | (#9603302)

I too have wanted to do something like this. Is anyone aware of a tool or filesystem that would do this? It's sorta in the back of my mind as an idea for a thesis, but I dunno how appropriate it'd be.

Re:Can't wait.. (1)

tono (38883) | about 10 years ago | (#9603144)

you just said a whole lot of stuff that doesn't mean anything.

Re:Can't wait.. (1)

bigattichouse (527527) | about 10 years ago | (#9603248)

Let me Clarify. I would like to get rid of the entire "tree" nature and move to something where I can interact with my files in a sort of "cloud"... by searching for things, or referencing things directly... things are found by reference, or relationships, and not by tree organization.

Re:Can't wait.. (1)

tono (38883) | about 10 years ago | (#9603278)

so you like not knowing what you're looking for, or not knowing what it is you're looking for? I'm sorry but I fail to see how your idea of a cloud is better than a well organized file tree?

Re:Can't wait.. (1)

ryanmfw (774163) | about 10 years ago | (#9603505)

While I agree that it is stupid to get rid of the tree, but, having a cloud does not eliminate knowledge of what you're looking for. Well, that's all I have to say, I couldn't care one way or the other, all I want is for Linux to support this *and* normal filesystems.

discussions about winfs and rdf (3, Interesting)

scupper (687418) | about 10 years ago | (#9603054)

Danny Ayers [] has some interesting discussion on his blog about winfs and rdf [] . There's also discussion of Jon Udell's Questions about Longhorn [] .

Haystack and Metadata efforts (4, Interesting)

Knight2K (102749) | about 10 years ago | (#9603073)

A group at MIT is using RDF for an integrated data management system. It's sorta like Outlook (or Kontact, if you prefer ;-) on steroids. It's called Haystack [] .

I have to say, their ideas are intriguing, but after using it... I think the big shortcoming is that it's tough to come up with a generalized user interface for manipulating any data thrown at it. Haystack tries at this, and I think, fails at providing any kind of cues or context that tells you what your are dealing with. In Haystack, every task and piece of information you deal with looks very much like every other piece of data, because, as a design choice, Haystack every piece of data has the same rank as every other piece of data.

Having different applications for different types of data usually make sense, if only to limit the amount of options presented to the user so they can make an intelligent decision about what action they want to perform. See this article on Slashdot about how users need limited [] since it makes decision-making too difficult psychologically.

Inevitably, discussions around RDF and metadata always devolve into hand-wavy discussions on how the computer will be able to "magically" do smart things based on the metadata. But it really isn't magic and it isn't automatic at all. Equivalencies and mappings have to be created by humans along with the rules about what to do.

RDF uses many concepts from AI research. Anybody who has read about this branch of computer science knows that the discipline has pretty much given up on creating AI in the 'sci-fi' sense as an impractical dream. That's what makes the Loebner prize [] so controversial. I don't expect that computers will be intelligent enough able to relieve users of too much of the burden in assigning metadata.

RDF is a promising approach, but if you read the article, it makes a lot of assumptions about what needs to happen to make the benefits real. Among them are establishing standards for what metadata fields apply to different types of objects: photos, people, music, etc. That kind of standardization won't happen overnight, if at all.

The computer also needs to know what to do when it encounters that kind of data. The article mentions MIME and browsers and, in effect, says the browser can make a rational decision even if it hasn't seen a particular MIME type before. That isn't really true.. you have to install a plugin that tells the browser what to do, or have a registry that someone has put together where the browser can install the right plugin at the right time.

That said, KDE's unification of contact information and passwords does show some of the promise of metadata efforts. And Apple's Spotlight looks like a good solution as far as it goes. I guess I'm just trying to make the point that the magic of metadata needs to be taken with a fairly large hunk of salt.

Separate the apps, not the data. (1)

Cardinal (311) | about 10 years ago | (#9603376)

Having different applications for different types of data usually make sense, if only to limit the amount of options presented to the user so they can make an intelligent decision about what action they want to perform.

I agree wholeheartedly that unifying desktop applications into one nebulous interface isn't a very useful way to give users access to their data. Mail clients make good mail clients, but they make lousy photo gallery browsers.

That said, what I do wish we'd see more of is an effort for different applications to share the same information, because the dividing line between which application to use is much clearer than the dividing line between which application should be the keeper of particular types of data.

I don't want to have to open my web browser to see if I've bookmarked a URI that somebody mentioned in an IRC channel. I also don't want to have to open my PIM to find the phone number of somebody who I'm talking to in that IRC channel.

These are the sorts of data access issues I'd like to see resolved, and I do see RDF as a possible, even attractive, approach to solving the problem. However, as you've pointed out, we can't simply modify our applications to all spit out RDF, and expect everything to fall into place. Some degree of consensus about how to represent data is required. Rather than writing new applications like Haystack, or looking for new approaches to managing one's information, I'd rather see efforts to modify existing applications to share data sources more effectively.

Many community websites don't permit RDF (2, Interesting)

MichaelCrawford (610140) | about 10 years ago | (#9603111)

I have a couple of articles that have Creative Commons licenses, and I tried at first to include RDF in them.

But when I tried to publish one article at Kuro5hin, the RDF code, which took the form of HTML comments, was displayed literally in the visible body of my article. That is, all the tags had been turned into entities so the tags appeared literally in the rendered text.

I think Kuro5hin's Scoop content management system doesn't permit HTML comments. Maybe it's not trying to suppress comments, but it didn't occur to scoop's developers to allow them.

RDF on the web would likely be much more popular if one could count on publication sites allowing it in the submitted markup.

Another problem I had is that Creative Commons' recommended way to apply a license to a web page is not permitted by any of the community sites I frequent. CC-licensed web pages usually have a small banner that links to the license text. But for obvious reasons, sites like Slashdot and Kuro5hin don't permit images in article or comment submissions.

The result is that, even for the copies of my articles on my own website [] , I use neither RDF nor the CC banner, because I want to make it easy for others to copy my CC-licensed articles to site that don't permit RDF or graphics.

The way I apply the license is the much-less-cool method recommended for plain text files. I have the following text appear in the body of my articles:

This work is licensed under the Creative Commons Attribution-NoDerivs License. To view a copy of this license, visit or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

Re:Many community websites don't permit RDF (1)

tono (38883) | about 10 years ago | (#9603210)

So a glorified forum is a content management system now? Christ.

Re:Many community websites don't permit RDF (2, Informative)

mlinksva (1755) | about 10 years ago | (#9603256)

You have another option -- put the RDF in a separate file and reference it with a link tag. See end#link []

Hey thanks for the tip (1)

MichaelCrawford (610140) | about 10 years ago | (#9603517)

I can do that. Thank you very much.

libferris && RDF (1)

monkeyiq (415791) | about 10 years ago | (#9603128)

A bit of a shameless plug, but none the less: I think that folks who
liked the ideas in Edd's article might also be interested in my
project, libferris [] .

Ferris allows metadata to be extracted from files and presented through
a uniform interface. It supports inference on metadata and has the
ability to index that metadata in many ways (eg. Berkeley db, odbc
LDAP). Note that the metadata index can be used to index anything
libferris can mount (XML, ODBC, RDF, LDAP, http, ftp...)

A cool thing related to Edd's piece is that you can read an inferred
attribute "as-rdf" to obtain all the metadata that libferris knows
about for a file as a single RDF/XML file.

mo3 Up (-1, Troll)

Anonymous Coward | about 10 years ago | (#9603146)

It's coming (0)

Anonymous Coward | about 10 years ago | (#9603162)

Of course you need a few extra things like a universal schema database so everyone can use he same schemss and a way to organise them, ratings, recommendation engine etc I can say, as an AC that it is nearly here, Windows to begin with (the core is cross platform C++ only the GUI is Wondows specific) before transitioning to a Mozilla based crossplatform app, the possibilites are far greater than the article discusses, a final unity of metadata, and more importantly search and aggregation across systems, datatypes, languages (human and machine).

Re:It's coming (1)

tono (38883) | about 10 years ago | (#9603184)

The "core" of windows is what makes windows, well, windows.. and is therefore not cross platform. do you even know what you just said?

Isn't it the same problem? (3, Insightful)

pyrrhonist (701154) | about 10 years ago | (#9603228)

After reading this article, I'm wondering if metadata is really going to be as effective as the author thinks it is. The author points out that, "the computer makes us do the work of a filing clerk". In other words, when you place a files on your computer, you normally place them into a folders to organize them, which is, "not fun". The author implicitly claims that metadata will solve this situation.

But that's the problem! If it's not fun to organize items into folders, how is it anymore fun to add metadata to a file? I'm not talking about text files. Text files are easy, because you can pull the metadata out of them automatically (in fact, you can do this now with search tools). I'm talking about files that have to be explicitly tagged with metadata, like pictures. How is adding metadata to each picture file to categorize your vacation pictures any less laborious than placing the vaction pictures into their own directory?

That's the problem as I see it. You still end up being a filing clerk! If people don't even organize their folders now, are people going to use metadata when it's available? Will improved search capabilities make users want to be clerks?

In a nutshell, isn't it the same problem?

Re:Isn't it the same problem? (1)

tono (38883) | about 10 years ago | (#9603254)

in a nutshell, yes, it is the same problem, one that can easily be solved with appropriate filenames. And don't tell me about the wonders of how metadata can hold more than just the name of the file and all this, by the time you add any useful information to the metadata the data describing the data will be larger than the original data itself. it's rediculous, and as I see it is just more self-maturbation on the part of bored jobless software engineers that aren't solving any problems that need solving.

Re:Isn't it the same problem? (2, Insightful)

value_added (719364) | about 10 years ago | (#9603344)

When I was a kid and would ask aloud where something was, my mum would say, "Look where you put it." It annoyed me to no end, of course, but years later I find myself "putting things where they belong" and emptying my mind of everything else, much like putting phone numbers in a phone book so one doesn't have to clutter up one's my mind remembering any of them.

My own opinion is that there is no substitute for "putting things in folders." Boring, but true. Regular expressions and databases can go a long way (even for the average Joe), but it's as brainless as it is fast to look in an appropriately named folder. Not everyone agrees, of course:

Apple Unveils Faster Searching []
Apple Throws Spotlight on Search []

Re:Isn't it the same problem? (1)

adamscottphotos (681121) | about 10 years ago | (#9603674)

I do a lot of reading. I have somewhere in the neighborhood of 1200 folders on various topics. I am also a photographer. I have over 26000 digital shots from all around North America, plus scans of my analog shots [] . I plan my trips in excruciating detail; I have at least 10000 links to various online maps, logs, and trail descriptions.

It's neither brainless NOR fast for me to 'look in an appropriately named folder'; there are simply vastly too many. Even with the best heirarchy I could conceive, I have over 70 top level folders.

Short of dewey-decimal, heirarchial folder systems simply do not scale from the user's perspective.

Re:Isn't it the same problem? (1)

CustomDesigned (250089) | about 10 years ago | (#9603428)

How is adding metadata to each picture file to categorize your vacation pictures any less laborious than placing the vaction pictures into their own directory?

It isn't. The file names are metadata. Links and Symlinks let you have multiple "metadata" entries. If directories represent categories, then you can link a picture into as many categories as applicable.

In terms of power, metadata support is equivalent to support for links. In fact, metatdata could also be encoded into long file names - but that could get pretty ugly. For instance, my company uses a homebrew filesystem where filenames can contain null chars. The normally visible part of a filename is terminated by a null char, and followed by arbitrary metadata in a conventional format - typically a database field table.

So there is no real need for special metadata support. Anything stored as metadata can be equivalently stored using some filename or directory bundle convention. The important thing is to define common conventions.

With the unix approach, in the worst case, with thousands of competing conventions, you can still backup and restore with your favorite tar or cpio like utility. If you go the special metadata route, on the other hand, you have to have specialized backup and restore utilities. This is a great feature for M$ (yet another way to lock you into their platform), but a huge drawback for open source.

Creative Commons & Desktop Metadata (1)

mlinksva (1755) | about 10 years ago | (#9603272)

CC is interested in desktop metadata developments. See this CC weblog post [] from a few days ago.

RDF is not practical (1, Insightful)

Anonymous Coward | about 10 years ago | (#9603474)

I've yet to see a real world example of how to use RDF that wasn't for research(ie to prove RDF works) purposes. Most of the projects listed for semantic web are purely research, toy projects, or completely unproven. I know of several companies that have tried, but they usually end up extending the hell out of RDF to make it practical and useful. That makes me think RDF is flawed.

what metadata is most important to describe? (1)

nusratt (751548) | about 10 years ago | (#9603621)

1. Ditto to the post which said, "Separate the apps, not the data." The current proliferation of app-specific formats is absurd and counter-productive.

2. I file hundreds of docs &/or URLs per day. I need something which offers some degree of assistance in immediate auto-categorization (e.g. Bayes) with feedback, while still allowing user-defined hierarchy. "Yes, thank you for intelligently recognizing that this new info is about device interrupts; but now I need to tell you that it's about kernel-coding vs. crash-debugging vs. performance-analysis."

3. One poster calls the article, "self-maturbation on the part of bored jobless software engineers that aren't solving any problems that need solving".
Speak for your yourself. Yeah, I'm a developer, but most of my minute-to-minute usage of my desktop isn't all that different from "lusers" or PHBs, i.e. massaging info.
Get some perspective. Your statement is like saying, "Cars are really primarily made for mechanics and automotive engineers, not for soccer moms and commuters."

4. Forked-data: sure, as long as it's restricted to the app-specific stuff. Take that table the user just created: use forked-data for the meta-data which is specific to the spreadsheet or WP app, but leave the table data as ASCII data which anyone can read.

5. Someone said, "a file-name should be enough". Speak for yourself; a lot of my needs go waaayy beyond that. If the metadata goes beyond your neeeds, then your course is clear: just don't use it. It costs you nothing to architecturally allow for its use by other people.

6. re: "clouds", there are times when I'd really like to know -- what app created this file? what OS? which host? which user? what other files had been opened (e.g., stdin)? what was the original volume label? etc.

Watching the XML kiddies reinvent the wheel (3, Informative)

Animats (122034) | about 10 years ago | (#9603627)

It's fun watching the XML kiddies re-invent concepts from LISP. They just re-invented property lists, "is-a" links, and much of the baggage that made SGML painful.

Knowledge representation via "is-a" links has been tried, and it breaks down rather quickly. Read "Artificial Intelligence meets Natural Stupidity", by Drew McDermott, for a 20 year old critique of this concept. It's overkill for searching, and not powerful enough for reliable automated question answering.

The Cyc debacle [] illustrates how much work you have to put into tagging to get very little out. After twenty years of that money sink, it's still useless.

RDF (and OWL) in Pike (3, Interesting)

janbjurstrom (652025) | about 10 years ago | (#9603694)

I noticed the article made no mention of Pike (also the name of a fish - see language logo). Pike's a fine C-like scripting language ...that I know extremely poorly myself, but anyway..

From Pike's official homepage [] (at the University of Linkoping, Sweden):

The release of Pike 7.6 marks the first results of a long-running project to make Pike the first scripting language for the Semantic Web. The current highlight in that respect is the support for W3C's standard formats RDF and OWL.

Worth downloading [] and checking out for other reasons [] than "just" RDF & OWL [] . Free software, available under LGPL, GPL, and MPL (Mozilla Public License).

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account