EagleFiler As a bookmarking tool and lock-in concern

I am evaluating EagleFiler and I like it very much so far.

One of the ways I would like to try using it is as a replacement for a bookmarking tool. Although EagleFiler accels at archiving, I believe Michael Tsai advocates - and I would tend to agree - that memory is cheap now, so why not archive your web page that you're bookmarking. I can't count the number of times I've gone back to find broken URL's or one's where the content has been completely changed - and in my experience that doesn't always mean the old content was irrelevant or poor. The point is, as I capture items from the web, I don't want to have to think about what should be captured as a bookmark versus an archive.

My Concern: Lock-In
Tools come and go. Work flows evolve. If I begin to capture all of my bookmarks in EagleFiler, then I want/have to get my bookmark info (at least) into another tool, do I have a lock-in problem? In other words, is there no way to get my URL's into another tool?

Specifically ...
Is there a way to export bookmark related information from EagleFiler?
What Type of information can be exported (url, tags, date, description, etc)?

I think at the bare minimum the user would need EF to locate every Webarchive, extract the source URL, and write it to a html file which a browser could import as bookmarks.
Can this already be done with EagleFiler? Maybe I just don't see it.
Can this already be done with a (simple?) Applescript?
I took a quick look at EF's Applescript dictionary and I don't think I see the commands that would support this.

Beyond the bare minimum ...
I. It would seem criminal to lose the tag data. (and any other "easily" exported metadata eg description/note). Should probably be exported in a format compatible with delicious.

Tools come and go. Work flows evolve. If I begin to capture all of my bookmarks in EagleFiler, then I want/have to get my bookmark info (at least) into another tool, do I have a lock-in problem? In other words, is there no way to get my URL's into another tool?

I’d argue that there isn’t any lock-in because the Web archive files are always accessible to other applications. The Web archive files store the original URLs, even though Safari doesn’t display them.

Originally Posted by PianoDon305

Is there a way to export bookmark related information from EagleFiler?

The easiest way is to select the Web archives in EagleFiler can choose Edit > Copy Source URL. That will get you all the URLs.

Originally Posted by PianoDon305

What Type of information can be exported (url, tags, date, description, etc)?

All of the metadata is available from AppleScript. EagleFiler also saves it in XML files.

Originally Posted by PianoDon305

I think at the bare minimum the user would need EF to locate every Webarchive, extract the source URL, and write it to a html file which a browser could import as bookmarks.
Can this already be done with EagleFiler? Maybe I just don't see it.
Can this already be done with a (simple?) Applescript?

EagleFiler does not have a built-in function to generate an HTML bookmarks file, but it should be simple to do that via AppleScript (maintaining the hierarchy and tags if you want).

keeping files in native formats is wonderful

Comment from a long-time user of EF:
Because EF keeps all files in their original formats, including Safari web archive format, there is very little difficulty with lock-in. You will end up with a large Mac folder of web archive pages, which can be opened in Safari natively. You may lose the link to the original web URL, but normally that can be re-searched with Google.

Folder hierarchies are also maintained by EF. However you arrange files and folders inside EF will be the way they are physically organized on the Mac, as well.

You may lose the link to the original web URL, but normally that can be re-searched with Google.

Although Safari doesn’t display the original URL, it’s stored in the Web archive file. So it could be interpreted by EagleFiler or another application that understands Web archives, or you could view it yourself, e.g. using Property List Editor.

Comment from a long-time user of EF:
Because EF keeps all files in their original formats, including Safari web archive format, there is very little difficulty with lock-in. You will end up with a large Mac folder of web archive pages, which can be opened in Safari natively. You may lose the link to the original web URL, but normally that can be re-searched with Google.

Folder hierarchies are also maintained by EF. However you arrange files and folders inside EF will be the way they are physically organized on the Mac, as well.

Thanks For the additional insights. Good points.

I still have a need for a more direct method to collect the URL's to export to another tool. The assumption here is that there are hundred's (or thousands) of URL's and it would not be practical to navigate the webachives in Finder and open with Safari. I would want them imported to a bookmark tool (or Safari's bookmarks). In this way, with one operation, I could maintain all my webarchives of past research in native format while I figure out what I want to do with them; and yet have the source URL's available immediately if needed to continue online research and reference URL's that I commonly use.

I can't apologize for wanting ...
1. own my data (native formats)
2. own the metadata (have reasonable access to it)
3. flexibility and ease of migration of data

It looks like EF delivers on #1 and #2 but could do a little better on #3 IMHO.
(and #3 for me includes import as well as export. I've had some problems importing both email and URLs.)

Would it be accurate to summarize by saying that you are requesting an “Export Bookmarks” command or script that generates a Netscape/Safari bookmarks file?

Yes. Although, like I said above, if it could optionally retain the tag data as well that would be great since this is critical metadata that goes with the URL.

I thought the importing URLs problem was solved. It’s not clear to me what the importing mail problem is, since from what you’ve described so far everything seems to be working correctly.

The importing URLs problem is solved. You are right in pointing that out.
I apologize.
As far as Email. My problem with Thunderbird importing was not resolved when I made that statement. And I am still running a test to confirm the solution. I posted an update on that thread about why the Thunderbird import was not working correctly.

My statement that EF "could do a little better on #3 IMHO" mainly is a carry-over
from the last two weeks of struggling with importing URL's and email. All I know is for people like me (odd?), there have been some recent problems.

That being said... I don't think I could find a better tool, with better import capability, or more responsive developer. And I have looked.

Either that (as a user option?) or could you optionally support the "del.icio.us format" (whatever that is) which seems to be the "standard" for formatting tagged URL's. There is a growing number of tools have the ability to read/write this format.

Either that (as a user option?) or could you optionally support the "del.icio.us format" (whatever that is) which seems to be the "standard" for formatting tagged URL's. There is a growing number of tools have the ability to read/write this format.

Thanks. I’ll take a look at that. At first glance, it looks like the Delicious (they changed the name) format supports tags and notes. I’m not sure whether it supports hierarchy, because I don’t think Delicious lets you create a hierarchy.

Thanks. I’ll take a look at that. At first glance, it looks like the Delicious (they changed the name) format supports tags and notes. I’m not sure whether it supports hierarchy, because I don’t think Delicious lets you create a hierarchy.

I believe you are correct. Delicious doesn't much care about hierarchy - they've always been about tags.
And from my perspective, I am transitioning from folder/hierarchy based information to tag based information as quickly as possible. So last week I was concerned about importing my old bookmarks and maintaining hierarchy because it's the only metadata/organization I have. But as I begin to use EagleFiler and extensively apply tags (and become a raving fan), the tags will become MORE valuable to me than the old hierarchy that was imported. So, down the road, if I had to choose between exporting tags or folders, I'd choose tags hands down. Although I'd prefer to export both if possible since I don't know how long it might take to migrate the old folder data into tags.