"Peter P. Jones" <ppj@concept67.net> writes: (01)
% I think you are perhaps half missing my point. :) I'll try even
% harder... (02)
Oh.. I am sure I am missing it completely. Whatever I am getting
is certainly not what you are talking about. (03)
% The input syntax is not really an issue for me, except that I would
% like whatever wiki-like tool I am using to treat using wiki words as
% an optional mode. As Eugene has pointed out, [[this syntax]] can be
% used effectively, and that is fine for me. I happen to think that
% syntax is far less error prone than the tendency to mistype
% WiikiWoordss, or worse still the tendency to misspell them anyway. (04)
I do not buy that WikiWords vs [[Wiki Words]] is any more or less
prone to mistype. (05)
% The output (display view) does matter for me, (06)
As it does for me. But I suspect in opposite ways.
I like having WikiWords. You don't like WikiWords (07)
Sometimes I really do want spaces in my WikiWords. (08)
And so [Wiki Words] would be my prefered solution,
but purplewiki uses [[Wiki Words]] because it interfers less
with regular text. (09)
However, what really would be nice, would be if the "abstract"
node could have different representations. There is no
reason that a wiki could not represent [[Wiki Words]] and
WikiWords as just different expressions of the same
object. (010)
you could have a knob that would adjust the view from (011)
This is a test of WikiWord syntax to see how
a set of WikiConcepts gets expressed. (012)
To (013)
This is a test of [[Wiki Word]] syntax to see how
a set of [[Wiki Concepts]] gets expressed. (014)
To (015)
This is a test of [[wiki word]] syntax to see how
a set of [[wiki concepts]] gets expressed. (016)
They all are just syntactic sugar in how they are presented.
and all represent the same real object. (017)
% as does the capacity to
% alias terms over a single link. (018)
I also agree that the simplistic WikiWords without aliases
is a problem. You should be able to say that
FooConcept and WikiConcept are the same object.
And there needs to be a way to break them apart. (019)
I am beginning to be a fan of FacetWiki which would allow
you to be more complex relationships between nodes. (020)
% But your point about assumed meanings resolves for me around how much
% of what you are worried about would go away if wiki words weren't
% used
% in the first place. Folks would still have to reinforce meanings by
% filling in the details relating to [[important matters]], but the
% text
% is easier to strip out, imho, and flows aren't broken as much. (021)
Why does lower case with spaces, but a different color
strike you as flowing better. Are you really concerned about
cutting text and pasting it into some other application? (022)
Do you need a perl script written that filters WikiWords
into wiki words? (023)
% As regards NLP tools, if you know of a an NLP POS tagger that won't
% go
% wrong when splitting out, say, BrandName or AlkOxyglycerols if one
% has
% just happened to split all 'WikiWords' into 'wiki words', please let
% me know. I don't see how to control this cleanly using simple perl
% regexes. (024)
Ok. I don't currently know of one. But since we have a parser ,
it is being done somewhere in the middle of
the wiki code. (025)
I will think on this.... (026)
You want a filter, which would take text in the form: (027)
This is a WikiWord which should not be confused with
AlkOxyglycerols (028)
And output: (029)
This is a wiki word which should not be confused with
AlkOxyglycerols (030)
However, this would get a bit munged up by things like (031)
WikiWords that beging in other contexts like
in the beginning of sentences, or when they
are used as a single WikiWord would probably not
get processed right. (032)
% These related points also impinge on the acceptability of wiki
% authored texts for academic purposes. (033)
Yes, academic traditions evolve slowly. But WikiWork
is designed for a different set of work. You would not complain
that Databases don't provide data that is acceptable for
database authored text. Because you expect to be able
to translate the data into a paper. (034)
But I think we can solve some of the issue with the filter.
I will ask dave about it. (035)
% Also, there's been a view that Wiki means quick and anything that
% isn't vanilla Ward Cunningham original would be slow or worse. I just
% think that whether the app is quick or not is a matter of mechanics
% and good interface design. (036)
Yes, I do not agree with some of the mythology around wiki's.
RadicalOpeness and WikiMeansFastInternals are two such concepts.
The goal is a tool to use, not a tool for exploring computer science
concepts (at least for me, now in this context). (037)
% I'm open-minded about wikis; I've played with them and they fail to
% meet my needs. I also cannot live in a mail inbox - it isn't
% sufficient for me. So I must attempt to move forward from that. (038)
Interesting. I spend lots of time in my MH inbox.. (039)
% Mostly I think that in order for you to see what I am getting I just
% need to build something that you can see and play with. It is
% underway. (040)
That would be great. (041)
% Cheers,
% --
% Peter
%
% On 10 Aug 2004 at 7:34, John Sechrest wrote:
%
% >
% >
% > "Peter P. Jones" <ppj@concept67.net> writes:
% >
% > % Hi,
% >
% > % I hear what the WikiWordHuggers are saying, and I've obviously
% > not % communicated my ideas that well. I'll try harder (and later
% > I'll just % go fork some code and build it).
% >
% > % * Whether I print out a displayed HTML version of a wiki page, or
% > the % marked text that was its basis, it is better if what I pass
% > to them % can be read as straight prose, without having to print
% > out a 50-page % glossary too. I also think being able to read prose
% > without having to % break off every other word to find out what the
% > heck the author is on % about is better.
% >
% > But... but... but.... when you are reading "straight prose" all of
% > the assumed and hidden meanings are laying there. They still need
% > to be figured out. But now, you have not clue from the author what
% > they thought was important, so you make them up on the fly and you
% > think you know what they are talking about, but you don't really.
% > So all the list of definitions and all the "find out what the heck
% > the author is talking about" is something that you should be doing
% > in any writing. However, because you believe that you can fill in
% > the blanks, you invent what the paragraph means, instead of having
% > help to know what it means.
% >
% > There are innumerable papers that would be more specific and more
% > communicative if they really did use an explicit glossary. And
% > innumerable arguments that would have never existed if people had
% > just defined thier terms. In fact some branches of philosophy are
% > nothing but getting explicit on what terms you are using (cynical
% > comment)
% >
% >
% > % * I come from a background where it is important to distinguish %
% > between genuine insights and what I'll term creative artefacts of
% > the % imagination. I have to be careful here because I know that
% > wikis are % used in different ways, but again, the need for
% > successful % interchange, integration, communication, etc. make an
% > overriding case % in my usage.
% >
% > Which suggests to me that you want to be more explicit about what
% > you are meaning when you say things, not less.
% >
% >
% > % * I would like wikis to upgrade beyond being a memory aid. I
% > would % like them to be a place I can do proper work in. As I see
% > it there % would be advantages to being able to author papers
% > directly into a % wiki-like environment, where connections are
% > picked up or easily % created. But I see WikiWords as a barrier to
% > this.
% >
% > What is it about the synatax that is a barrier to this?
% > Would you feel happier if you had a post processor that hide
% > the wikiwords and turned them into none wikiwords?
% >
% >
% >
% > % * I would like to be able to use NLP tools on my texts without
% > lots % of % ugly pre-processing, and without those tools chucking
% > lots of errors % about parse failures.
% >
% > Like which tools?
% >
% >
% >
% >
% > % Having said all of that, the key point for [[John Sechrest]] is
% > how % in % some piece of text I indicate [[an important concept]].
% > That's the % input (taking Eugene's cue about the brackets). When
% > processed using % the urlencoding the output HTML would look like,
% >
% > % <p>Having said all of that, the key point for <a
% > % href="John%20Sechrest">John Sechrest</a> is how in some piece of
% > text % I indicate <a href="an%20important%20concept">an important %
% > concept</a>.</p>
% >
% > % But those URLs don't have to consist of the urlencoded text. They
% > % could just be a system ID reference. It doesn't really matter.
% > But % being able to separate out control of the URL allows for the
% > indexing % of terms by the parser to make different pieces of text
% > that are % defined to be aliases point to the same page.
% >
% > using WikiWord or [[Wiki Word]] or <a href=blah>Wiki Word</A>
% >
% > is just choosing a parser. And I would submit that typing
% > WikiWord has far fewer syntactic errors than the other two when
% > people are typing naturally.
% >
% > I do not see why you think that
% > using <a href=blah>Wiki Word</A> is any better. It is just
% > syntax. And it is cheap and easy to convert between the three. But
% > the typing for the user and the user experience is not the same. So
% > do you need a parser that has a view that makes all WikiWords into
% > <a href=blah>wiki words</a>?
% >
% >
% > % Some of these additions would require a DB on the back end. I
% > don't % see why that is a problem, since most wikis are already
% > using some % sort of versioning system. We might as well take full
% > advantage of % the % tools available.
% >
% >
% > I must be totally missing your point. Why does this require a DB on
% > the backend? We are talking about syntax issues. I have seen no
% > structural issues raised. What structural issues need dealing with?
% >
% >
% >
% >
% >
% >
% > % On 9 Aug 2004 at 9:33, John Sechrest wrote:
% > %
% > % >
% > % > ;-) ;-)
% > % > Ahhh now I know my calling ... I am a WikiWordHugger!!!
% > % > Nice to know.
% > % >
% > % > I find that the syntacic marker of doing WikiWords
% > % > is valuable as a marker of SomethingImportantGoesHere.
% > % >
% > % > It is not the same to say that without the marker for
% > % > wiki words that something important did not go there.
% > % >
% > % > IE, in the second version, how do you know what I was
% > % > finding important?
% > % >
% > % > would it be better if I were to say:
% > % >
% > % > I find that the syntacic marker of doing <a href=WikiWords>wiki
% > %
% > > words</a> is valuable as a marker of <a % >
% > href=SomethingImportantGoesHere>something important goes here</a>.
% > %
% > > % > % > ... I find that this breaks the flow of writing. And
% > > makes
% > it had to % > write as clearly or as effectively. % > % > If the
% > WikiSquirm is activated by the CamelCase formating, % > what other
% > SyntacticSugar would make for good KnowledgeCrafting? % > % > % >
% > Define KnowlegeCrafting % > % > KnowledgeCrafting is the process of
% > organizing information and % > using it to create deeper
% > understanding. % > % > Good KnowlegeCraftingTools support features
% > like: % > *Easy ability to enter data and information, so that the
% > flow of an % > idea is easy. *Easy liking to other related concepts
% > %
% > > % > % > WikiWords support this type of liking and make for an
% > > easy
% > flow. A % > failure of WikiWords is that they cause WikiSquirm. And
% > that there % > is a need for WikiWordAliases % > % > % > EndWord %
% > > % > Define WikiSquirm % > % > WikiSquirm is that feeling that
% > some people get when they % > look at what they suspect is english
% > in a KnowledgeCraftingTool, but % > which because it has CamelCase
% > words, they get an uncomfortable % > feeling. % > % > What is an
% > alternative SyntacticSugar that would enable easy linking % > and
% > easy flow of information, but which reduces WikiSquirm. % > % >
% > WikiWordHuggers are people who have a low threshold and do not % >
% > experience WikiSquirm. % > % > We want a way to have a syntax for
% > saying % > SomethingImportantGoesHere. % > % > EndWord % > % > % >
% > Define SomethingImportantGoesHere % > % > A syntax marker that
% > identifies that there is a key concept or key % > relationship
% > here. WikiWord syntax using CamelCase is used to make % > this
% > designation. How can we find a SyntacticSugar that reduces % >
% > WikiSquirm, but still is able to say SomethingImportantGoesHere % >
% > % > EndWord % > % > % > Define WikiWordHugger % > % > Someone who
% > has a love of CamelCase words and copes % > well with WikiSyntax.
% > And who does % > not experience WikiSquirm when a WikiWord is used
% > to say % > SomethingImportantGoesHere. % > % > % > % > EndWord % >
% > % > % > Define WikiSyntax % > % > The use of CamelCase WikiWords to
% > identify % > SomethingImportantGoesHere. It is a form of
% > SyntacticSugar that %
% > > marks where links need to be made to other ideas. % > % > % >
% > EndWord % > % > % > Define SyntacticSugar % > % > The WikiSyntax
% > uses CamelCase as the syntactic marker for where % > ideas go. % >
% > % > % > % > EndWord % > % > % > Define CamelCase % > % > The
% > process of creating WikiWords uses Capital Letters in the middle %
% > > of words as a form of SyntacticSugar to mark where links are % >
% > created. % > % > % > % > EndWord % > % > "Peter P. Jones"
% > <ppj@concept67.net> writes: % > % > % On 8 Aug 2004 at 20:18,
% > Eugene Eric Kim wrote: % > % % > % [...] % > % > % > % > Three
% > thoughts: % > % > % > % > * Even folks who are Wiki-literate do
% > not always use Wikis in % > the % >
% > pattern you describe above. % > % > * On good Wikis, % >
% > gardeners (or WikiGnomes) generally emerge and do % > things %
% > > like convert terms to WikiWords after the fact. % > % > * Even
% > % > folks who are both Wiki-literate and immersed in the % >
% > pattern %
% > > % > described above will not always know in advance what
% > > should
% > % > be a % > % > WikiWord. % > % > The advantage of an
% > ontology-oriented Wiki is % > that it better % > supports the
% > gardening pattern. When I read a % > page, and I see % >
% > something that should be a WikiWord, I just do % > it right there.
% > But % > I often don't % [...] % % I think some of % > that is
% > upside down, and thus a barrier to unskilled % use. What I % > mean
% > by that is that usually what triggers *me* to think % of % >
% > creating a new page to address some subject matter is usually a % %
% > > phrase I've already written. (This is a sticking point for me in
% > % > the % use of wikis - they fail a squirm test in forcing
% > wiki-words % > on me.) % % It looks to me like the use of wiki
% > words within % > something like a % wiki % isn't necessary, it's
% > just a mode. % % % > Eccentric person that I am, what I want to be
% > able to do is just % > wrap % the phrase I've written in some
% > simple syntax like % > ~~something % important to define later~~
% > as I write, and then have % > that urlencoded % to create the link
% > in the wiki machinery. So a % > link URL is the % urlencoded form,
% > and the content is the % > urldecoded form (the ordinary % text).
% > (Am I right in thinking that % > text typed into the address bar %
% > of % a browser gets automatically % > urlencoded these days, or do
% > some % browsers not do that?) If that %
% > > makes for ugly links then just have % the % urlencoded text % >
% > replaceable by a WikiWord or similar with some access % mechanism %
% > >
% > the user can edit it with. But the point for me is that the % % >
% > WikiWords should never live on the surface. Not least because if %
% > > they % don't you can define aliases for the text content that go
% > to %
% > > the same % subject page. As I see it, WikiWordsAsURLsAreABodge %
% > > >
% > intended to get % around the fact that URLs don't have meaning as
% > %
% > > anything other than % an identification string. (Wasn't that a
% > bone % > of contention with % purple numbering once?) % % Lastly,
% > with a % > system like the above then it is probably possible to %
% > just have a % > mode switch that replaces all the highlighted
% > phrases % with % > whatever the URL is using, so WikiWordHuggers
% > can get their % % > little friends back whenever they like. % % --
% > % Peter % % -- % % > This message is archived at: % % % >
% > http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=tools-yak&i=41
% > %
% > > 17 B3B2.15812.410FE6@localhost % > % > ----- % > John Sechrest
% > >
% > . Helping people use % > .
% >
% > computers and the Internet % > .
% > more effectively % > .
% >
% > % > . Internet:
% > sechrest@peak.org % > . % >
% >
% > . http://www.peak.org/~sechrest % > % >
% > --
% > % > This message is archived at: % > % >
% > http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=tools-yak&i=20
% > 0 % > 40 8091633.i79GXUX27888@jas.peak.org % > % > % > % % %
% > ------- End of forwarded message ------- % % -- % This message is
% > archived at: % %
% > http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=tools-yak&i=41
% > 18 B50F.8597.3DADE7@localhost
% >
% > -----
% > John Sechrest . Helping people use
% > . computers and the Internet
% > . more effectively
% > .
% > . Internet: sechrest@peak.org
% > . . http://www.peak.org/~sechrest
% >
% > --
% > This message is archived at:
% >
% > http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=tools-yak&i=200
% > 40 8101434.i7AEYU417136@jas.peak.org
% >
% >
% >
%
%
% ------- End of forwarded message -------
% ------- End of forwarded message -------
%
% --
% This message is archived at:
%
%
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=tools-yak&i=411A078A.14080.53D0FE@localhost (042)
-----
John Sechrest . Helping people use
. computers and the Internet
. more effectively
.
. Internet: sechrest@peak.org
.
. http://www.peak.org/~sechrest (043)
--
This message is archived at: (044)
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=tools-yak&i=200408111503.i7BF3Bm14286@jas.peak.org (045)
|