Re: [ba-ohs-talk] Keyword Indexing
Eric Armstrong wrote: (01)
> Murray Altheim wrote:
>
>
>>I suggest this:
>>
>> [KEYS: word1, word2, word3 ]
>>
>
> Makes sense to me. Especially if not case sensitive. (02)
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]. (03)
>>Alex Shapiro wrote:
>>
>>>*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.
>
> Given the lack of a selection interface, ease and speed of typing is the jey, so
> to
> speak. Underscore is the hardest to hit. Dash is easier. Capital letters easest,
> due to long practice and familiarity. (04)
You really can't use underscores in text that may become a hypertext (05)
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_. (06)
If you camelcased words, you could never differentiate between the (07)
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
confusion). (08)
>>>*4.2* FINE GRAINED KEYWORDS: Besides basic keywords there can also be
>>>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.
>>>
>>Yes.
>
> Sounds good to me, too.
>
>>>The idea is that we should eventually settle on some common keywords by
>>>convention. ...
>>>
>>Look 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,
>
> Perhaphs [KEYS: x=y] could create a synonym? Of the course, that only
> works if a word doesn't like to have multiple meanings, depending on
> context. We're going to need to avoid those anyway, though. (09)
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." (010)
Murray (011)
......................................................................
Murray Altheim <http://kmi.open.ac.uk/people/murray/>
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK (012)
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut. -- Minamoto no Tsunenobu (013)