[PD] representning classes and selectors in the wiki
badmuthahubbard at gmail.com
Mon Oct 8 13:02:59 CEST 2007
I haven't been too active with Pd lately, but I just got a P5 glove and a
new idea, so back I come. I'm very happy to see this discussion.
All I have to add is that, if there is a good search engine, I'll love it.
Personally, when I'm looking for a particular external, or to find an
external for a particular purpose, I don't bother wading through
categories. Perhaps a search that is able to filter for .dll, .c, UNIX
executables, etc.? Or to search for libraries that contain a particular
I'm burned on Google, it gives me too much. I wonder if that might be
improved if, in tandem with creating new references, some of the old ones
would be taken offline, or even just tagged with links to more recent
On 9/13/07, Hans-Christoph Steiner <hans at eds.org> wrote:
> Marius and I had a powwow about the pdpedia structure of the pages,
> and I think we are in agreement with this proposal. Here's the outline:
> - Basically, it's as much like wikipedia as possible. For class/
> object names, the canonical page for each object would be the
> 'mylibrary/myobject' format, then there would also be a 'myobject'
> page, which would be a redirect or a disambiguation page, depending
> on the circumstance.
> - Everything else would go into the same room namespace, like
> wikipedia. Then for things that need disambiguation, there would be
> things tacked on, like wikipedia, like 'float (selector)'.
> - about caps, I figured out how to make mediawiki keep things all
> lowercase. The problem is that wikipedia doesn't use mediawiki that
> way, so it might have strange problems. We'll see...
> - like roman said, I think that all things Pd are welcome in the
> pdpedia. Libraries that are not in Pd-extended should follow the
> same naming scheme, i.e. mylibrary/myobject.
> On Sep 12, 2007, at 11:17 AM, IOhannes m zmoelnig wrote:
> > marius schebella wrote:
> >> how stable is the library structure? if it is stable over several
> >> years,
> >> then it could be arbitrary. but some objects jump around. from
> >> zexy to
> >> iem (mtx?), from iemlib1 to iemlib (don't know if that is really the
> >> case...) from iemlib to puredata core (gui)... from everywhere to
> >> "flatspace".
> > wow:
> > zexy had the matrix objects for several years (they first appeared
> > therein in 2001; and they vanished by 2005)
> > iemmatrix has the matrix objects for several years too (2005-today)
> > iemlib consists of 3 binary libraries (iemlib1, iemlib2, iem_t3) and a
> > collection of abstractions; this has not changed since i know this
> > library (which is quite some time)
> > i don't know which object has moved from the sub-package "iemlib1" to
> > the meta-package "iemlib". i thought this would be impossible,
> > given the
> > structure of the iemlib.
> > let us not be troubled by repackaging of objects.
> > all in all, if the system cannot handle renames, we should dump it
> > immediately
> > but then, wikipedia does handle renames, e.g.:
> > http://en.wikipedia.org/wiki/Puredata
> > http://en.wikipedia.org/wiki/Pure_Data
> >> why not keep a flat structure:
> > because we could at the same time put library and object information
> > into the same database?
> > .../pdp => doc on the pdp lib
> > .../pdp/pdp_qt => doc on a certain object.
> >> the title of the page does not represent the real name of the object
> >> anyway. wiki does not support titles/pages starting with lowercase
> >> letters. that means the real object name will be shown at some place
> >> inside the page content. therefore we can call the page counter
> >> (markex)
> >> which will show up as:
> >> http://pdpedia.at.or.at/test/index.php/Counter_%28markex%29
> >> or counter.maxlib. or maxlib.counter.
> > what exactly is the difference between maxlib.counter and maxlib/
> > counter?
> > can mediawiki handle both?
> >> only information. therefor if structure helps the understanding like
> >> (math/plus) then structure is good. but as I said before structure
> >> for
> >> categories is not really possible, so better no structure...
> > my only argument is: the grouping structure of objects is the one the
> > original author has made explicit by grouping them together in a
> > library.
> >> it is not related to structure, but to the possibilities for
> >> searching
> > right
> >> and displaying objects and libraries. and to page design.
> > well, even though in times of phishing i daresay that few people will
> > actually look at the link.
> > and the page need not reflect the link anyhow.
> > (i guess that the page "/maxlib/counter" will display "counter" as
> > title)
> >>> the important thing is to have a good search engine!
> >> that was the reason why I did not want to go for the wiki at
> >> first. but
> >> the wiki has more advantages on other points.
> > hmm, the wiki search engine does a full text search and you can
> > specify
> > multiword queries.
> > this should pretty much do... (at least i got quite used to getting
> > multiple hits when i google :-))
> > what else do you want to find?
> > mfga.sdr
> > IOhannes
> > _______________________________________________
> > PD-list at iem.at mailing list
> > UNSUBSCRIBE and account-management -> http://lists.puredata.info/
> > listinfo/pd-list
> You can't steal a gift. Bird gave the world his music, and if you can
> hear it, you can have it. - Dizzy Gillespie
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list