|[Date Prev] [Date Next] [Thread Prev] [Thread Next]||Indexes: Main | Date | Thread | Author|
Eric Armstrong wrote:
Murray Altheim wrote:
I suggest this:Makes sense to me. Especially if not case sensitive.
[KEYS: word1, word2, word3 ]
The big thing is being able to (case insensitively) grep on "[keys:]".
One can't simply use square brackets because they show up all the
time in both program code and prose, eg., [Humbert, 1999].
Alex Shapiro wrote:Given the lack of a selection interface, ease and speed of typing is the jey, so
*3* KWD FORMAT: We need to agree on some sort of word separation
standard for keywords. The above thread has contained the following
formats: FooBar, Foo_Bar, Foo-Bar.
speak. Underscore is the hardest to hit. Dash is easier. Capital letters easest,
due to long practice and familiarity.
You really can't use underscores in text that may become a hypertext
link, since it's impossible to ascertain the underscores (given that
most hypertext link display styles are already underlined). I don't
think phrases should be altered by adding hyphens or camelcasing them,
since that is actually creating new words and phrases. A comma is
pretty simple to type and is (in English) a _word_ or _phrase_delimiter_.
If you camelcased words, you could never differentiate between the
phrases and say, product names, eg., is "FooBar" a mnemonic for "foo bar",
"Foo Bar", or "FooBar"? I wouldn't strongly recommend we not encourage
people to corrupt their choice of key words or phrases, since the search
engines would have to disentangle them later (adding ambiguity and
Sounds good to me, too.*4.2* FINE GRAINED KEYWORDS: Besides basic keywords there can also beYes.
fine grained keywords, such as IBIS, Google, Graphs, etc. My suggestion
is that instead of wasting time arguing about these, we allow any user
to use any keyword. New keywords will automatically be added to a database.
Perhaphs [KEYS: x=y] could create a synonym? Of the course, that onlyThe idea is that we should eventually settle on some common keywords byLook at the SUO list to see that this is a pointless battle. You shouldn't
try to legislate this at all. I think we should have a topic map engine
and some manual labour to provide synonym matching periodically,
works if a word doesn't like to have multiple meanings, depending on
context. We're going to need to avoid those anyway, though.
I think this would be done in the map, not the document. Synonyms
should be handled there, and if unwanted merges happen between topics,
one can alter the map to say "these two things are not the same."
Murray Altheim <http://kmi.open.ac.uk/people/murray/>
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut. -- Minamoto no Tsunenobu