Your confusion here seems to stem from your beleif that labels and saved searches are the same thing. They are not. Let's use SQL as an example for a moment. This is what a saved search would look like:
select * from FILES f JOIN METADATA m on m.fileid = f.id where m.value LIKE 'Bills'
This is what a Label looks like:
--FILES table------- id name 12 American City Credit Card Bill
--LABELS table------ id name 15 Bills 16 Unpaid Bills 17 American City
Thus the method for looking up files that have the Label "Bills" is:
select * from FILES f JOIN FILE_LABELS_RELATIONSHIP r on r.fileid = f.id JOIN LABELS l on l.id = r.labelid where l.name = 'Bills'
And what do we get? All documents that have been explicitly linked to "Bills". In the case of Labels, there's no question of a file being missed or an extra file being added because there is no search criteria other than the Label itself.
In short Labels are a method in addition to saved queries that allows users to do away with traditional folders. They can not only do everything that a traditional folder can do, but the labels themselves improve the richness of the meta-data. Just from attempting to organize things, the system already knows that the document is an unpaid bill from American City. That sort of organizational detail is difficult to impossible in a strict heirarchy.
Someone mentioned it was an excellent product (but slow to update), but I've never actually seen anyone use it...
You're only likely to see it if you do desktop publishing. I've seen it twice in my career. Once in the advertising department of a company I worked for, and another time at a local newpaper office. I've also indirectly seen Quark by the crud-for-PDF documents its generates. (That I then have to fix. I know WAY more about the PDF format than I ever wanted to know. GRRRR.)
Think home directories shared from a central server to a bunch of desktops. AFS, Coda, NFS....
No worries, I'm thinking just fine. To the *desktop user* there's no reason to mount the directories directly into the file system. Windows doesn't do it today, and people don't complain (except for server side work where it would be really nice).
I think what you'll see in the next few years is that server side technology and desktop technology will grow apart, yet have a symbionic relationship. Most of the Unix style concepts work great on a server. So there's no need to get rid of those. Yet those same concepts tend not to work very well for a desktop. So there, we'll see a different interface. The two will meet when they need to work together. e.g. The server will happily provide a database file repository (i.e. File Server) to the desktops with full support for meta-data. However, the server itself could care less about the meta-data, and only provides tools to manage the repository.
Make sense? One of these days, I'm going to do a write up of the neat directions I think desktops vs. servers will go on my new blog. So keep an eye out, you should see a lot more detail very soon.
Yes, but now you're mixing a couple different things. "Bills" is simply a descriptive term for your search results, and you would get the same effect by renaming a Smart Folder named "Bills" to "Credit Card Bills." While #2 is easier to set up, #1 is still capable of handling it.
How does my Smart Folder know that only credit card bills go in it? i.e. What's to prevent it from also picking up an email I send to my spouse, or something not related at all, but just happens to match the search criteria?
*Tick*, *tick*, *tick*
Well, one idea is that we could label them with "Credit Card Bills" so that the search will always get the right files.;-)
The idea behind labels is that you always get exactly what you put in a folder. Saved searches (e.g. Smart Folders) are quite nice as well, but both have a place.
Re:What's taking so long? A: IT WILL NEVER WORK
on
The Death of Folders?
·
· Score: 1
Question: Do you use the iTunes interface for burning CDs? If you answered "Yes", then you've already used the described type of interface.
His hostility is unwarranted... but his concerns aren't.
I have no issue addressing concerns that people may have. It was his hostility and made up issues that turned myself and others off.
When all the useful metadata gets stripped out on your colleague's machine, and they send the file back to you, what then?
The question is, how much meta-data do you get today? The answer is, only a small amount. Creation, Modified, File Size, File Name, and Path are about it. Other than Path, they're all there and can be transferred just fine. And for Zip programs and the like, Labels/Smart Folders can be used to fake the path.
Re:PHP definitely does not follow the KISS princip
on
A Decade of PHP
·
· Score: 1
1. What is a PLP file?
2. I'll be nice and forgo any attempts to append ';drop database; to the query strings.;-)
The former is what you're thinking of. The later works as a form of folders, like GMail's labels. IF I realized that "Bills" is suddenly not descriptive enough for Credit Card bills, I should be able to rename it to "Credit Card Bills".
There are, of course, different takes on how Meta-data should work, but labels make for a nice method of partly keeping folders.:-)
I can foresee problems where people will think they are operating on two different files and make two different sets of changes to the same file.
That has occurred to me as well. I think that the only real solution is to ensure that the interface promotes the idea that these are labels and not folders. There's nothing wrong with presenting a folder view to the user, but labels should be applied to a file instead of overloading the copy mechanism. If a user drags the file somewhere, they should be asked if they want to make a copy. It probably wouldn't hurt either if files of the same name were automatically shown to the user as a "Are you sure you didn't mean this file?"
Another example: you do a find and get files from removable media or networked drives, then make a Smart Folder to treat those files like a regular folder.
That's a no no. Labels need to be stored on a per-repository basis. Searching all media is fine, but a Label should only show the files that are on that drive. The result is that the user might have the same label under "Macintosh Hard Drive", "MyFileServer", and "CDROM" all containing different files. That shouldn't cause much confusion for the user, and will ensure that the psuedo-directory structure is in place for anyone else who looks at the media.
What about the idiot that does a query that finds half the files on his computer and mistakenly labels them as being part of a big project he's working on, then tells an assistant to delete all the files with that label after the project is over? No problem. Instant disaster.
Sadly, this happens with the folder metaphor too. In some ways the folder metaphor is worse, because users accidentally drag massive numbers of files into folders that they hadn't intended. Usually, these get caught before anything is lost, but sometimes you need to go to a backup.
You can't go around deleting other people's mail or Google's system files by mislabeling something. On a computer, abandoning the references to a file's physical location is probably not a good thing to promote.
Keep in mind that security models still apply to files in a shared repository. If you aren't in a group that can see Bob's files, you won't see them. But Joe, who's in my department, can see my files. (And happily delete them, GRRRR.)
Just so you're aware, you can already download the Alpha version. If you're really interested in the OS, then trying it out and giving constructive feedback may be helpful to the project.:-)
I think the kids really dig it when I "get down" verbally.
(Bonus points to first person who can identify the gag.)
Re:Congratulations are in order!
on
A Decade of PHP
·
· Score: 1
Maybe I didn't make my point clear -- the question I intended to ask is why is a database independent API even useful if the code you're passing to it is DB specific anyway?
For the reason I originally stated. It's easier to fix the SQL to be portable than it is to fix every instance of API usage. Plus, the abstract API does not prevent you from tying yourself to the database if you so chose.
The NeXT developers had almost NOTHING to do with this.
Except build the APIs, the OS, the file system, etc., etc., etc.
The search/index technology was called VTwin before it was called Spotlight and it has been part of Mac OS since Mac OS 8.
You're confused. V-Twin is Sherlock, a slightly different technology. Spotlight is made possible by new OS features that extract, read, index, and categorize file meta-data.
The integration into the file system was done by one of BeOS's engineers (I don't remember his name) who now works for Apple.
His name is Dominic Giampaolo. He joined Apple in 2002 after stints at Google and QNX. He had designed a similar Meta-Data system for BeFS, and definitely brought understanding and experience with the technology to the NeXT team.
I hate to break it to you, but Copeland is dead and Mac OS only lives on as the phatom "Classic Environment". Most of the tech in OS X came from NeXT, with some bits pulled from the Copeland project (e.g. Blue Box)
Someone else mentioned comments, and they do sound like they fit the bill. The only catch to watch out for is that the comments are actually linked to by the file, and not just applied as free text. The reason for this, is that if I change the text of the comment, it should get changed across all files. If it doesn't, then we have a problem.:-)
On the other hand: In the interest of interoperability, and fostering a more usable computer ecology, Apple should make sure that the design and implementation of their abstractions are published. If they don't, then doublem's hostility is warranted....And I wouldn't know if that information is available or not.
No offsense, but it's still a file. As long as a file can still be copied as a stream of bytes with a name, then his inferior system can handle it. Previous versions of Mac OS handled resource forks poorly and made everyone's life difficult. But back then, Windows also crapped out twice a day and made all your files available over the internet. Technology has moved on.
In a modern Mac system, a file is just a file. The file system keeps all kinds of meta-data about the file, but an inferior system couldn't use that if it wanted to. And even if it did, most of that data is repository specific, so it's useless outside of the context of the FS it's stored in.
And FWIW, his hostility appears to be toward ALL implementations of database file systems, not just the Macintosh one. And that is the sign of a closed mind. My hope is that he'll walk away from this today, think about it a little, then eventually come to understand the idea in its entirety. He may even come to like the idea.
Either way, his hostility is unwarranted, and his comments about pirates and pr0n are unwelcome.
For example, the labelling in GMail is useful but you soon build up lots of labels - what's next? You want to start organizing them into folders of labels.
Categories, actually. Pretty close to the same thing.:-)
My point is that the Tree Heirarchy concept will never go away. It makes sense. What *will* go away is the forced heirarchy of current systems. To use an example from another poster, do I put the bill from the university in Bills or University? With labels, the answer is "Both". Thus the labels become both a useful folder structure for categorizing data, as well as adding meta-data that can be searched on.
e.g. Type "Bills from the University" into the meta-data search, and what do you get? Neat, huh?:-)
Re:Congratulations are in order!
on
A Decade of PHP
·
· Score: 1
Why do you insist on confusing database specific SQL with database specific APIs when I clearly pointed out that the latter is all I'm asking for? That is a REALLY annoying thing to do. Not to mention that it does zip to help the conversation.
All I asked for is a simple API for db_open, db_query, db_commit, etc. instead of having mysql_open, mysql_query, postgresql_open, postgresql_query, etc, etc, etc.
NFS. The remote system is just another directory. It isn't another device
Sorry, it's something that needs to be rethought for Desktop usage. For servers, NFS without database file systems makes perfect sense. But for a desktop, mounting remote directories can be confusing and potentially outright dangerous to system stability and file integrity. (e.g. What happens when I unplug my laptop?)
Oh, and what you're really getting at is using NFS via VFS. There's nothing in NFS that says it MUST be mounted into the VFS. That's just how most VFS systems work, so that's how it's used. SAMBA is used the same way on Unix machines despite the fact that Windows machines treat SMB servers as separate devices.
Re:So the metaphor is more like...
on
The Death of Folders?
·
· Score: 2, Informative
Mathematically, it's like sets, yes. Sets are core to database theory, and file systems are a form of database. The catch is that current filesystems are missing a lot of relational theory that could improve their usability.
Metaphorically, it's like using a label gun to apply those little stickers that say "Property of XYZ". If you were to lump together the labelled objects from my wife, kids, and myself, some stuff would be labelled mine, some stuff would be labelled my wife's, some stuff would be labelled with a kid's name, and some stuff would have a mixture of labels. e.g. Wife/Husband, Kid1/Kid2, Wife/Husband/Kid1/Kid2 ~= Family Property (Family Property could be an alternative label for everyone.), etc.
Of course. And I considered demonstrating that, but I didn't want to confuse the issue. The point I was trying to make was the difference between meta-data as a FS entity and meta-data as a freeform string. Anything else would have confused the issue.:-)
This can be troublesome if you work with files that are highly related. "Did I file that bill from the University under 'Finance' or under 'School'?
Under a stored query system (i.e. Labels), you could place the bill under *both* University and Finance. That's why labelling makes more sense than folders.:-)
As a basic principle of database design, saved queries will never be as fast as stored data.
Unless they're precomputed. If one thinks about it, a folder is really just a precomputed query against all files that have the same meta-data attribute (the path). If you update the pre-computed table for a label each time the label is applied to a file, you can obtain the same performance as a traditional file system.
Of course, I'm not certain that you'd get much bang for your buck that way. Doing a query against an index (itself just a fast method of accessing a pre-computed list) is only marginally slower. With computers being as fast as they are, the difference in performance would likely be unnoticable.:-)
Select file, Apple-i, go to Spotlight Comment, add your label, then create a smart folder thatt looks for that spotlight comment (which you unfortunately have to look for under 'Other.'
Sounds pretty darn close. The only question remaining is, is the comment stored in its entirety (bad) or is the file linked to the comment (good). Thanks for that info. I really need to get upgraded to Tiger. I'm just being a lazy scaredy cat (ha ha) who's afraid of having to deal with breakage from the upgrade.:-)
How are folders not meta-data? Hint: They are. The key is that folders are a single entity that things link back to. The difference between arbitrary meta-data and Labels is that arbitrary can be mistyped. Labels, OTOH, are a solid node in the system that things link to. Consider the following SQL tables:
--WRONG----- create table FILE (
data BLOB NOT NULL,
label Varchar(255) NULL ) --/WRONG----
--RIGHT----- create table LABEL (
id Integer Identity Primary Key,
Name Varchar(255) NOT NULL )
create table FILE (
data BLOB NOT NULL,
label Integer references LABEL.id ) --/RIGHT----
Slashdot Mirror
In short Labels are a method in addition to saved queries that allows users to do away with traditional folders. They can not only do everything that a traditional folder can do, but the labels themselves improve the richness of the meta-data. Just from attempting to organize things, the system already knows that the document is an unpaid bill from American City. That sort of organizational detail is difficult to impossible in a strict heirarchy.
Someone mentioned it was an excellent product (but slow to update), but I've never actually seen anyone use it...
You're only likely to see it if you do desktop publishing. I've seen it twice in my career. Once in the advertising department of a company I worked for, and another time at a local newpaper office. I've also indirectly seen Quark by the crud-for-PDF documents its generates. (That I then have to fix. I know WAY more about the PDF format than I ever wanted to know. GRRRR.)
Think home directories shared from a central server to a bunch of desktops. AFS, Coda, NFS....
No worries, I'm thinking just fine. To the *desktop user* there's no reason to mount the directories directly into the file system. Windows doesn't do it today, and people don't complain (except for server side work where it would be really nice).
I think what you'll see in the next few years is that server side technology and desktop technology will grow apart, yet have a symbionic relationship. Most of the Unix style concepts work great on a server. So there's no need to get rid of those. Yet those same concepts tend not to work very well for a desktop. So there, we'll see a different interface. The two will meet when they need to work together. e.g. The server will happily provide a database file repository (i.e. File Server) to the desktops with full support for meta-data. However, the server itself could care less about the meta-data, and only provides tools to manage the repository.
Make sense? One of these days, I'm going to do a write up of the neat directions I think desktops vs. servers will go on my new blog. So keep an eye out, you should see a lot more detail very soon.
Yes, but now you're mixing a couple different things. "Bills" is simply a descriptive term for your search results, and you would get the same effect by renaming a Smart Folder named "Bills" to "Credit Card Bills." While #2 is easier to set up, #1 is still capable of handling it.
;-)
How does my Smart Folder know that only credit card bills go in it? i.e. What's to prevent it from also picking up an email I send to my spouse, or something not related at all, but just happens to match the search criteria?
*Tick*, *tick*, *tick*
Well, one idea is that we could label them with "Credit Card Bills" so that the search will always get the right files.
The idea behind labels is that you always get exactly what you put in a folder. Saved searches (e.g. Smart Folders) are quite nice as well, but both have a place.
Question: Do you use the iTunes interface for burning CDs? If you answered "Yes", then you've already used the described type of interface.
:-)
Thank you, please drive through.
His hostility is unwarranted... but his concerns aren't.
I have no issue addressing concerns that people may have. It was his hostility and made up issues that turned myself and others off.
When all the useful metadata gets stripped out on your colleague's machine, and they send the file back to you, what then?
The question is, how much meta-data do you get today? The answer is, only a small amount. Creation, Modified, File Size, File Name, and Path are about it. Other than Path, they're all there and can be transferred just fine. And for Zip programs and the like, Labels/Smart Folders can be used to fake the path.
1. What is a PLP file?
;-)
2. I'll be nice and forgo any attempts to append ';drop database; to the query strings.
Er... why should it?
:-)
Because there are two types of meta-data:
1. Free form meta-data
2. Category type meta-data
The former is what you're thinking of. The later works as a form of folders, like GMail's labels. IF I realized that "Bills" is suddenly not descriptive enough for Credit Card bills, I should be able to rename it to "Credit Card Bills".
There are, of course, different takes on how Meta-data should work, but labels make for a nice method of partly keeping folders.
I can foresee problems where people will think they are operating on two different files and make two different sets of changes to the same file.
That has occurred to me as well. I think that the only real solution is to ensure that the interface promotes the idea that these are labels and not folders. There's nothing wrong with presenting a folder view to the user, but labels should be applied to a file instead of overloading the copy mechanism. If a user drags the file somewhere, they should be asked if they want to make a copy. It probably wouldn't hurt either if files of the same name were automatically shown to the user as a "Are you sure you didn't mean this file?"
Another example: you do a find and get files from removable media or networked drives, then make a Smart Folder to treat those files like a regular folder.
That's a no no. Labels need to be stored on a per-repository basis. Searching all media is fine, but a Label should only show the files that are on that drive. The result is that the user might have the same label under "Macintosh Hard Drive", "MyFileServer", and "CDROM" all containing different files. That shouldn't cause much confusion for the user, and will ensure that the psuedo-directory structure is in place for anyone else who looks at the media.
What about the idiot that does a query that finds half the files on his computer and mistakenly labels them as being part of a big project he's working on, then tells an assistant to delete all the files with that label after the project is over? No problem. Instant disaster.
Sadly, this happens with the folder metaphor too. In some ways the folder metaphor is worse, because users accidentally drag massive numbers of files into folders that they hadn't intended. Usually, these get caught before anything is lost, but sometimes you need to go to a backup.
You can't go around deleting other people's mail or Google's system files by mislabeling something. On a computer, abandoning the references to a file's physical location is probably not a good thing to promote.
Keep in mind that security models still apply to files in a shared repository. If you aren't in a group that can see Bob's files, you won't see them. But Joe, who's in my department, can see my files. (And happily delete them, GRRRR.)
Just so you're aware, you can already download the Alpha version. If you're really interested in the OS, then trying it out and giving constructive feedback may be helpful to the project. :-)
And we have a winner! :-P
Never...
...check your references.
Always...
I think the kids really dig it when I "get down" verbally.
(Bonus points to first person who can identify the gag.)
Maybe I didn't make my point clear -- the question I intended to ask is why is a database independent API even useful if the code you're passing to it is DB specific anyway?
For the reason I originally stated. It's easier to fix the SQL to be portable than it is to fix every instance of API usage. Plus, the abstract API does not prevent you from tying yourself to the database if you so chose.
This was all in my post.
They're called Smart Folders in Mac os X Tiger.
Yes, we've covered that.
The NeXT developers had almost NOTHING to do with this.
Except build the APIs, the OS, the file system, etc., etc., etc.
The search/index technology was called VTwin before it was called Spotlight and it has been part of Mac OS since Mac OS 8.
You're confused. V-Twin is Sherlock, a slightly different technology. Spotlight is made possible by new OS features that extract, read, index, and categorize file meta-data.
The integration into the file system was done by one of BeOS's engineers (I don't remember his name) who now works for Apple.
His name is Dominic Giampaolo. He joined Apple in 2002 after stints at Google and QNX. He had designed a similar Meta-Data system for BeFS, and definitely brought understanding and experience with the technology to the NeXT team.
I hate to break it to you, but Copeland is dead and Mac OS only lives on as the phatom "Classic Environment". Most of the tech in OS X came from NeXT, with some bits pulled from the Copeland project (e.g. Blue Box)
Someone else mentioned comments, and they do sound like they fit the bill. The only catch to watch out for is that the comments are actually linked to by the file, and not just applied as free text. The reason for this, is that if I change the text of the comment, it should get changed across all files. If it doesn't, then we have a problem. :-)
On the other hand: In the interest of interoperability, and fostering a more usable computer ecology, Apple should make sure that the design and implementation of their abstractions are published. If they don't, then doublem's hostility is warranted. ...And I wouldn't know if that information is available or not.
No offsense, but it's still a file. As long as a file can still be copied as a stream of bytes with a name, then his inferior system can handle it. Previous versions of Mac OS handled resource forks poorly and made everyone's life difficult. But back then, Windows also crapped out twice a day and made all your files available over the internet. Technology has moved on.
In a modern Mac system, a file is just a file. The file system keeps all kinds of meta-data about the file, but an inferior system couldn't use that if it wanted to. And even if it did, most of that data is repository specific, so it's useless outside of the context of the FS it's stored in.
And FWIW, his hostility appears to be toward ALL implementations of database file systems, not just the Macintosh one. And that is the sign of a closed mind. My hope is that he'll walk away from this today, think about it a little, then eventually come to understand the idea in its entirety. He may even come to like the idea.
Either way, his hostility is unwarranted, and his comments about pirates and pr0n are unwelcome.
For example, the labelling in GMail is useful but you soon build up lots of labels - what's next? You want to start organizing them into folders of labels.
:-)
:-)
Categories, actually. Pretty close to the same thing.
My point is that the Tree Heirarchy concept will never go away. It makes sense. What *will* go away is the forced heirarchy of current systems. To use an example from another poster, do I put the bill from the university in Bills or University? With labels, the answer is "Both". Thus the labels become both a useful folder structure for categorizing data, as well as adding meta-data that can be searched on.
e.g. Type "Bills from the University" into the meta-data search, and what do you get? Neat, huh?
Why do you insist on confusing database specific SQL with database specific APIs when I clearly pointed out that the latter is all I'm asking for? That is a REALLY annoying thing to do. Not to mention that it does zip to help the conversation.
All I asked for is a simple API for db_open, db_query, db_commit, etc. instead of having mysql_open, mysql_query, postgresql_open, postgresql_query, etc, etc, etc.
NFS. The remote system is just another directory. It isn't another device
Sorry, it's something that needs to be rethought for Desktop usage. For servers, NFS without database file systems makes perfect sense. But for a desktop, mounting remote directories can be confusing and potentially outright dangerous to system stability and file integrity. (e.g. What happens when I unplug my laptop?)
Oh, and what you're really getting at is using NFS via VFS. There's nothing in NFS that says it MUST be mounted into the VFS. That's just how most VFS systems work, so that's how it's used. SAMBA is used the same way on Unix machines despite the fact that Windows machines treat SMB servers as separate devices.
Mathematically, it's like sets, yes. Sets are core to database theory, and file systems are a form of database. The catch is that current filesystems are missing a lot of relational theory that could improve their usability.
Metaphorically, it's like using a label gun to apply those little stickers that say "Property of XYZ". If you were to lump together the labelled objects from my wife, kids, and myself, some stuff would be labelled mine, some stuff would be labelled my wife's, some stuff would be labelled with a kid's name, and some stuff would have a mixture of labels. e.g. Wife/Husband, Kid1/Kid2, Wife/Husband/Kid1/Kid2 ~= Family Property (Family Property could be an alternative label for everyone.), etc.
Of course. And I considered demonstrating that, but I didn't want to confuse the issue. The point I was trying to make was the difference between meta-data as a FS entity and meta-data as a freeform string. Anything else would have confused the issue. :-)
This can be troublesome if you work with files that are highly related. "Did I file that bill from the University under 'Finance' or under 'School'?
:-)
Under a stored query system (i.e. Labels), you could place the bill under *both* University and Finance. That's why labelling makes more sense than folders.
As a basic principle of database design, saved queries will never be as fast as stored data.
:-)
Unless they're precomputed. If one thinks about it, a folder is really just a precomputed query against all files that have the same meta-data attribute (the path). If you update the pre-computed table for a label each time the label is applied to a file, you can obtain the same performance as a traditional file system.
Of course, I'm not certain that you'd get much bang for your buck that way. Doing a query against an index (itself just a fast method of accessing a pre-computed list) is only marginally slower. With computers being as fast as they are, the difference in performance would likely be unnoticable.
Select file, Apple-i, go to Spotlight Comment, add your label, then create a smart folder thatt looks for that spotlight comment (which you unfortunately have to look for under 'Other.'
:-)
Sounds pretty darn close. The only question remaining is, is the comment stored in its entirety (bad) or is the file linked to the comment (good). Thanks for that info. I really need to get upgraded to Tiger. I'm just being a lazy scaredy cat (ha ha) who's afraid of having to deal with breakage from the upgrade.
How are folders not meta-data? Hint: They are. The key is that folders are a single entity that things link back to. The difference between arbitrary meta-data and Labels is that arbitrary can be mistyped. Labels, OTOH, are a solid node in the system that things link to. Consider the following SQL tables:Make sense?