I don't want to learn SQL, so like the idea of having a nice UI for the main functions, with bare-naked SQL available for those skilled in the art.
-rjbull
Sorry, if you thought I was suggesting that anything in this requirement of yours should not be met. I apologise for not explaining myself very well above. I was suggesting pretty much exactly what you say you do/don't want here. No disagreement at all, though I would not use a tautology to describe SQL.
I don't see OCR as a must-have. When I used to have to extract data from scanned-image PDFs of patents, I was content to use a separate application do the job. The more so, as OCR is often imperfect, so it was better to put the converted text into an editor/word processor for spell-checking and reformatting.
-rjbull
Sorry again if I did not not explain myself very well above. It's not that I disagree with what you say, it's just that I think we have to strive to move forwards in the use of technology, to use it more effectively and efficiently, and to overcome the constraints of that technology. History has shown that we can do this. That's how we got men on the moon, for example. In our OCR case, I can better explain if I make a comparison:
OCR is to data gathering/extraction what push-button dialling was to the telephone. I feel sure that some people may have felt that the push-buttons were an annoying but passing fad and didn't work terribly well, but would we be advantaged nowadays by retaining the circular phone dial? The answer is self-evident - "No". Though I have to admit that I dislike push-buttons on cellphones, because my finger-ends are too large and spatula-like for the smaller buttons, I would not recommend returning to the dials.
I'm not keen on tags/keywords. You have to know what you need in advance, and be consistent in applying them. I'd rather have really good retrieval from title + body text of the clips, which is why I like to see Boolean searching. If you must have keywords, then yes, it would be nice to be able to apply them to multiple clips at a time. Also to have a CintaNotes-like feature where you had some kind of drop-down or auto-completion.
-rjbull
Sorry again if I did not not explain myself very well above. I share your lack of keeness for tags/keywords, and for pretty much exactly the same reasons as you give. Which was why being able to turn a group or "favourite" into a VF (Virtual Folder) in CHS - by enabling the use of some SQL - blew me away. That's exactly what you need to enable Boolean searching, see? It's what you want, and it was exactly what I had been used to using in Lotus Agenda.
VF = Virtual Tag. As a worked example, I decided that I wanted to filter out all those records (clips in CHS) that contained a reference to one of the main religions. So I used my budding arcane knowledge of SQL to write an SQL filtering statement like this:
((Lower(ClipText) LIKE '%islam%') OR (Lower(ClipText) LIKE '%muslim%') OR (Lower(ClipText) LIKE '%roman catholic%') OR (Lower(ClipText) LIKE '%christian%') OR (Lower(ClipText) LIKE '%anglican%'))A user-friendly UI would turn that into a VF with the name "Religion" with something like this:
("Islam" OR "Muslim" OR "Roman Catholic" OR "Christian" OR Anglican")For obvious reasons, I want to be able to perform these Boolean searches on date and time fields. I would also want to have
Condition-->Action, where Boolean Conditions can be used to result in an Action: e.g. IF ("Islam" OR "Muslim" OR "Roman Catholic" OR "Christian" OR Anglican") THEN Keyword = "Religion". Though you don't really need to do that in this case, because you can simply check to see if a record is a member of a VF/group named "Religion", forcing or setting a Keyword or label like "Religion" has the advantages that you can automate the labelling of many records at once (saves time over manually setting each record to that Keyword) and that
once you have done that you can then disable the SQL that did it, thus ensuring that your population of "Religion" records is fixed at that point, unless you directly manually assign other records to that Keyword at a later stage. This has a lot to do with "flexibility" in creating your meta-data - you can meet your data managment needs very precisely.
I don't expect very close integration with an e-mail client. There are too many clients to service them all. I can either include information through the clipboard, or by exporting from TheBat! and importing or clipping the resulting text file.
-rjbull
Sorry again if I did not not explain myself very well above. The requirement is to use emails (some, not all - only those that you feel would be useful) as records in your database. Importing sent/received emails to the database from an email client or from a web-based email service would suffice.
I learned from my experience of Info Select: Version 7 was integrated with Outlook, which was of no use to me as I did not use Outlook. Version 8 started to abandon Outlook integration, and incorporated its own rather good email client. I used that email client to manage most of my email, though I tended to continue to use Pegasus - the email client I preferred at that time - for managing Listserver groups. Info Select 8 enabled you to convert emails (which were in text or html format) to plain unformatted text, at the press of a button - a very handy feature.
It should be possible to store everything within the database, even if only a copy, to make the database portable and easier to back up.
-rjbull
Whenever I read that such-and-such "should" be the case, it usually means that what I have read is an arbitrary, unsubstantiated opinion (unless there is some special law or rule that supports it). The case would seem to be no different here.
I would recommend that we leave the design of the database to the engineers who are building the thing - or, as my mother used to say to me, "Don't teach your grandmother to suck eggs." The engineers are usually far from stupid, and are likely to be able to fully appreciate the need for portability and backup and a few other things, some of which we might not even have thought about, as well.
In the case of CHS, we seem to have the text records held
within the database, and the image clips as .PNG files held in a defined folder
outside of the database. There will be good theoretical and/or pragmatic reasons for this.
I just want CHS to become a really good storage and retrieval database for information that passes through the clipboard, with an accent on Web clips, as well as a transient clips tool.
-rjbull
So do I, except that CHS looks to me as though it is
already a pretty good database to hold clipped data/images, enabling increasingly flexible and sophisticated filtering/tagging, sorting and retrieval - through the use of SQL (that enables Boolean search filters). CHS now retains the source URL of clipped data, and I think
@mouser is probably contemplating how best to deal with partial/whole web clips without reinventing the wheel.
Flagging records as "permanent" or "transient" could be done by enabling some of the functionality decribed above - as I put it (above), "This has a lot to do with "flexibility" in creating your meta-data - you can meet your data managment needs very precisely."
