In article <[EMAIL PROTECTED]>,
"Adam M. Goldstein" <[EMAIL PROTECTED]> wrote:
> On Apr 28, 2008, at 1:28 PM, James Howison wrote:
>
> >
> > There are obviously pros and cons of controlled vocabulary. The major
> > one, from the perspective of an open source project, is that
> > maintaining them is administration heavy. I don't think it's
> > appropriate for BibDesk, or any application, to take on that task.
> >
> > Now if there were a source of a known controlled vocabulary, managed
> > by someone else and available online in a machine parse-able format,
> > then one could conceivably design a field in BibDesk that would only
> > accept keywords in that vocabulary (and perhaps make cross-referencing
> > suggestions, depending on the semantic machinery provided by the
> > keyword controlling authority). Was that more what you had in mind?
> >
> > --J
>
>
> I think it would be nice just to have the ability to create a
> controlled vocabulary for one's self, that is, to have a term list
> independent of the keywords that are entered into the keyword fields.
> Maybe a CSV file could be loaded in.
What would you do with it?
> Note that you can do something somewhat like controlling your own
> vocabulary by setting the groups pane to show keywords; Then you see
> things like "Philosophy" and "philosophy," and you can consolidate.
It's still unclear to me what the OP is asking for, so I've avoided
commenting on it. I believe groups are case-insensitive, though, so the
scenario you mention shouldn't occur.
> That won't work, of course, if there are terms that are not
> linguistically alike, but you want to use as synonyms.
>
> The issue of nested groups has come up many times on this list (though
> not recently, I am pretty sure) and Christiaan and Adam have always
> said it was too difficult; I would imagine that that remains their
> opinion for this case too.
My objection is more philosophical than technical: I think nested groups
are worthless unless you start out from scratch as a fanatical organizer
and continue that consistently. Searching and smart groups are more
flexible and useful in the long run, in my opinion, and you're not
limited by poor initial organization choices.
Nested smart groups sound more useful on the surface, but even then I
don't think there's much practical benefit. I could have
Sediment
Morphology
Critical stress
Transport models
Cohesive
Non-cohesive
where each is a smart group subset of an original smart group, but what
does that accomplish? It's easier just to search the "Sediment" group
for the term(s) of interest and weed out the false hits, or just create
an ephemeral smart group for the topic of the moment.
--
adam
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Bibdesk-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
