I'm playing around with v. 7.24 (fresh download and install) to see if I want to "upgrade" from v.6, and I've run into some issues with categories having the same name. Namely...
1. In my v.6 database there were 5 reference folders, each containing a child folder called "primary" plus some other child folders; the contents of each "primary" folder was different from the other 4 "primary" folders. When I opened this database in v.7, it converted all of my old folders into categories with the exact same visual tree structure.
But what actually happened is that it dumped the references from all 5 "primary" folders into a single "primary" category that appears in 5 different places in the category tree. So now, when I click on "primary" in Category 1, it shows the exact same references as when I click on "primary" in Category 2 or Category 3, etc. This is a very poor conversion of my folder scheme.
Better: If there is a potential naming conflict like the one I've described above, then the converter should prompt the user for new names or, perhaps, automatically create new names during the conversion (e.g., "primary - 1", "primary - 2", "primary - 3" etc.).
2. Renaming a category to another category name that's already being used can easily create a mess. What seems to happen is that when you rename Category A to Category B (when a category with that name already exists), both instances of Category B now include all the references from the old Category A plus all those that were originally in Category B. E.g., if the old Category A had 500 references and Category B originally had 300 references, clicking on either instance of Category B in the category tree will now give you a list of 800 references.
That's fine if it's what you wanted, but if it's not what you wanted then it's not easy to undo. In fact, I don't know how to undo it. If you change the "new" Category B to a new name, the remaining instance of Category B will still show those 800 references.
Better: when the user tries to name a category using a name that's already in use, BS should give a warning message.
3. Overall, I don't like that, for instance, I cannot create a child category called "education" in parent category "Japan" and a child category called "education" in parent category "Korea" such that they show unique lists of references. Instead, I have to name the child categories something like "education - Japan" and "education - Korea". This results in ugly category names, and it seems to defeat the purpose of having a category tree in the first place.
Am I missing something here? Are categories in BS7 really just tags?
Chris, sorry about the
Chris, sorry about the problems you experienced when converting versioni 6 database to version 7. Version 7 changed the way records are organized. It created problems for some users who organized references like you did. For users who had used the same names for several folders in versioin 6, I don't see a good way to convert to version 7. It is better to changed folder names in version 6 before you upgrade the database to version 7. The categories module in version 7 has two main functions. The first one is tagging. Tagging is simple to use, but it does require using unqiue names. Using your old database as an example, I would create tags "Japan", "Korea" under one branch. I would create other tags like "Education", "Research", etc. under another branch. Then you can tag a reference with two tags "Japan" and "Education". Later, you can hold down the Ctrl key to select those two categories to retrieve all those records tagged with both categories. For multi-faceted properties, using one dimension deep folder with duplicate names is not the best solution. The second main feature of categories module is linking. Linking does allow duplicate names. You can also add relationship for a link.
I am sorry about the inconveniences for versioin 6 users with duplicate folder names. Please rename folders in version 6 between the conversion.
many-to-many in versions 6 and 7
I think it's Alt+Ctrl to make an AND selection.
Yes, this will approximate my old BS6 filing scheme, but it won't be as precise as the old scheme because doing an AND selection will sometimes include references that don't belong.
For example, let's say I have (in my old BS6 system) a folder structure like this:
And let's say that Reference X is included in child folders Japan--Education, Japan--History, and Korea--Education (but not Korea--History because the reference doesn't say anything about Korean history). In the BS7 scheme this will mean that Reference X would be tagged with all these tags: Japan, Education, History, Korea.
Now, if I do an AND selection for Korea AND History, what's going to happen? If I understand correctly, Reference X will be included among the results because it's tagged with both Korea and History. For me, this is unfortunately not a useful many-to-many approximation of what was available in BS6.
The only way I can see to work around this is to use longer, more precise, unique names for the tags, like "Japan - Education" or "Japan - History", and in cases where I need to be more precise, even longer tag names like "Japan - History - Meiji" or "Japan - History - Postwar". This seems like not such an elegant solution either.
Personally, I can't see the advantage of having only simple "flat" tags instead of categories that can be nested within other categories.
Yes, I see the problem in
Yes, I see the problem in your case. The problem is caused by using the same term "Education" to represent two things, "Japan Education" and "Korea Education". In the next patch release, Biblioscape will warn user when a duplicate category is created. Unique term is the basic requirement of tagging. The hierarchical strcuture helps organizing tags. The order and structure is fluid. You can refind the structure as the project goes along. The category names stay the same and are used to organize records. So the order and tags should be separated. Biblioscape does provide some tools to take advantage of the hierarchical structure, like the categories popup menus "Search plus children" and "Search plus descendents".
Multiple categories folders
Thanks for your reply. I was hoping that maybe I could find a solution by creating a new, separate categories folder (in the Folder List pane). E.g., have a Project A categories folder and a Project B categories folder. But that doesn't help either. What happens is that when you create a tag in Project B that's already being used in Project A, it automatically inherits all the references associated that tag in Project A.
Well, I'll keep thinking about this. Please let me know if you have any other ideas for things (tricks?) I might try. Thanks again.
Chris, we are discussing the
Chris, we are discussing the possibility to create a new kind of folder called "Link Folder". You can drag and drop references to there, Biblioscape will create a link for you. Then you can easily retrieve records. It is similar to the way older versions of Biblioscape works. So we will have regular folders (one to many, a record has to be in a regular folder); search folders (any query can be saved as search folder for easy re-run); and link folders (a record can be in many link folders). There are also the categories for tagging, and cross module linking (topic maps).
While I agree that such
While I agree that such functionality would be highly appreciated I'm not sure if I would like to have another kind of folders. Wouldn't it be possible to integrate the desired functionality into existing categories? For example:
1. Clicking on a category would retrieve only those records which were assigned to exactly this category. In the example above: clicking on the "History" child in "Japan" category would NOT retrieve records of the Korea child. Basically, this means running a search Japan+History, thus preserving the absolute path of a category. (It is what the old folders did).
2. In the context menu, add something like "Retrieve all occurrences" which would retrieve all records tagged with that category. (This is what is done by categories now, and personally I like this tagging functionality).
3. "Search Plus Children" and "Search Plus Descendants": In my opinion, this makes most sense with functionality No. 1 but less with No. 2 (because the Korea child "History" does not belong to the children/descendants of Japan). Therefore I would appreciate if the existing commands could be made path dependent.
What do others think?
Lars
Tagging cannot be made to
Tagging cannot be made to work the way Chris wants unless unique names are used. Or the tag has to include the path which is not a good idea. Path is dynamic because the hierarchical structure should be adjust through out the project. The only way to make Chris way of organizing works is to use linking. So a link folder just points to a record resides in a regular folder. This makes it possible to use the same link folder name and points to different records.
I would LOVE to see that
I would LOVE to see that implemented (especially if it included "Search plus children" and "Search plus descendants"). That, with tags, would be a fantastic combination.
Maybe we can continue discussing this "Link Folder" in a separate thread, so that more people will have a chance to join in.
Link Folder(s) Topic
Just to say that as chris suggested it is here:
http://support.biblioscape.com/node/1121
Link Folder(s)
I also think that this Link Folder(s) might be a good idea even though I am not sure I grasp what it will be. If it is basically a non-destructive implementation of B6 folders it could be useful but than what is the conceptual difference between keywords and categories? Both seem to be tags, can be looked up, etc.
Also, if the link folders are implemented maybe it would be a good idea to host them in an additional tab? Is that what you are thinking? Next to where Categories live? Or next to "normal" folders?
Please do a search for link
Please do a search for link folder and limit it to book page. I will add more about link folder to the online books.
I would like to know that
I would like to know that too (and have asked before). If duplicate names are not supported, as it seems, this should be made clear and it should be impossible to create them. Otherwise, serious problems occur.
Duplicate names seem to be
I don't know if users should be prevented from creating them, but BS should at least warn users when they're about to create a duplicate name, because the risk for problems is very real.