hey marius, 

okay, well i think we're on the same page here, what you describe 
and what's in my head seem to be somewhat aligned. i have a little 
bit of time spare at present and a fair bit of experience 
developing web based content management systems, so hopefully these 
ideas could gather a little momentum.

what is important here is that there is a layer that is consistent 
between all interfaces connecting to it (ie. the database), and the 
way that this inforation is organised and presented can vary 
depending on the interface. 

it is also very important to make sure that the reference is 
maintainable, and where possible self documenting. this is where 
your data mining experiments are valuable, any statistics that we 
can easily gather, help to build the picture of how pd operates, 
and could certainly aid in the development of pd into the future. i 
know there is a limit to what can be automated and often automated 
content is more of a pain than a help, but a few small things may 
help with maintenance issues. 

for example plugging into the output of CIA (which pd is a 
subscriber to), should allow the object database to easily monitor 
changes to the svn, which in turn could create a section 
of 'watched' objects that would provide a list of known changes to 
objects (however small) and warn potential contributors that the 
object internals have changed and the reference may need to be 
updated.

when i initially started building my own database, i wanted to have 
a little picture of the object being described, with all of its 
inlets and outlets present. i decided to draw this using GD (a php 
graphing app), but in order to do so i had to document the inlets 
and outlets that were present, and those that were created 
dynamically on init - which meant documenting the init arguments 
too. this small exercise in futility helped expand the reference to 
include a bit more detail on each class, which i now recognise is 
invaluable to the database (and myself) having a stronger knowledge 
of pd internals. and now i have something that could potentially 
draw *basic* pd patch code without having to use pd as a server, or 
analyse pd patches with finer precision.

another example, i used your CSV file to build a small sh script 
that can analyse a pd patch and an abstraction folder, and list 
missing objects (and unique objects for that matter) required for 
that patch. with a bit more work this could very easily direct 
users to the libraries they're missing. (i realise that loading the 
patch into pd spits out this sort of information anyway, but there 
are times where i would like to check this first - and yes running 
pd-extended probably sorts out everything anyway, but that isn't 
always possible).

while the current list of objects and abstractions is quite 
intimidating, getting at least the object list completed and 
finding methods to extract the rest may be quite easily achieved. i 
think as you say making this database as approachable as possible 
to users, so that they can upload, comment, rank and favourite 
patches/abstractions/objects, will make pd generally a more 
inclusive environment and something that becomes a solution to more 
peoples problems. in a sense the more people that are contributing 
to higher level projects, the more interest there is in documenting 
the lowerlevel objects. i think this is in a sense where hcs is at 
with pd-extended, but what is missing with pdpedia/plone.

for me the plone space is buried in the logic of private spaces - 
places to hold your projects (home folders), but not really to mass 
distribution in a true wiki sense, or as you describe it 
a 'youtube' space (which is indeed a better metaphor for the 
distribution of patches/objects/libs etc)

so yeah.. this seems to be a shared interest and something 
potentially to build upon.. on a side note, i took up this project 
a few years ago when pddb finally breathed its last breath, which 
for me was the best resource for searching the object library 
outside of hassling the pd-list. i still don't think pdpedia has 
filled those shoes, which were in fact very simple and tidy, but i 
digress.. 

thanks for your encouraging response!

dmotd

On Thursday 09 April 2009 18:24:13 marius schebella wrote:
> hi dmotd,
>
> your post is great, it reminded me of all the ideas I had before
> starting pdpedia.
> my main motivation for working on a pd(pedia) object
> database/documentation was to help users (including myself) find
> the right object for their purpose and help developers by
> preventing redundancy in writing new objects. -- I also got stuck
> by the limitations of mediawiki.
> some of the things, for example that I'd like to see:
> make heavy use of *data mining* in existing pd patches: It should
> be possible to know, how often an object is used, and how often
> it is connected to which other object and which objects share the
> same window. it should even be possible to tell the search engine
> where in the patch (x/z area) an object was placed.
> I want to search for objects related to key words, tags, maybe
> categories (although a fixed structure is definitely a bad idea),
> libraries, similar objects, sort by all kinds of means (date,
> popularity, operating system).
> On top of this pd-base there should be a place like *youtube*,
> where you can post your own patches, have favorites, have a list
> of favorite objects. I know that it is not possible (yet) to play
> a pd patch within a browser, but I am sure someone will come up
> with a firefox plugin anytime soon.
> I also think that people should be able to comment on objects, or
> rate them, or have rss feeds if someone posts a new patch that
> contains a certain object or is related to a certain topic.
> and your point about exchanging data formats is extremely
> important, too. I know that mediawiki has a method to
> import/export - in theory, but this can by no means compared to a
> real query api.
>
> of course, maintaining all that information is a hell of a work.
> that was the point where the wiki idea came into place (a lot of
> people contributing). but after a year of pdpedia I still don't
> see this taking off, which makes me want to try out something
> new. btw is there any literature or real world examples of how
> other groups/open source communities deal with the *lack of
> physical/financial resources*?
>
> marius.
>
> 2009/4/9 dmotd <dm...@gmx.net>:
> > hi folks,
> >
> > i am somewhat interested in investing some time in pdpedia, but
> > i have a few concerns with mediawiki as a container for pd
> > related data.
> >
> > obviously mediawiki is an excellent versioning platform and has
> > a strong following for many technical wiki's in the open-source
> > community. i think its an excellent format for plain text
> > information, which takes the form of tutorials/howto/guide, but
> > as an object reference it has a limited scope.
> >
> > this is especially the case when attempting to pull that
> > information into another format (ie.. not html). anything
> > pulled off the server using the api needs to be parsed to be
> > made useful in another context, and in many cases reparsed to
> > pick out the
> > meta-references, and this is without getting to the content
> > which is often categorised in an entirely different format.
> >
> > i have previously invested a fair chunk of time in refencing
> > objects in a sql database, while my work was not designed with
> > versioning in mind, it was designed to be utilised by pd (dd
> > was the projected environment) or pd libs internally, or in
> > other formats like a postscript reference or generating pddp
> > formatted helpfiles. i have recently started picking up the
> > pieces of this project (which i had ceased with the initial
> > announcement of pdpedia).
> >
> > anyhow, what i am beginning to see a need for is an
> > infrastructure like mediawiki which stores pd files rather than
> > plain-text. think of it like a categorised + tagged svn. this
> > would be a place where people can upload files relating to pd
> > use, examples of usage, methods of interfacing and anything
> > else that gets passed around on this mailing list. keeping with
> > the same wiki format of edits by anyone, and versioning each
> > subsequent edit. then in a similar method to mediawiki api
> > calls, pd internally could request a list of articles
> > (pd-patches) and dynamically retrieve requested articles from
> > the pdwiki. thus making the system much more usable within the
> > pd environment.
> >
> > i think the benefit of this would be quite obvious to pd-users,
> > as it has been stated many times by numerous people that a
> > plain text wiki reference doesn't really make much sense
> > without the interactive characteristics of an actual patch.
> >
> > this is something i would happily put energies into
> > development, and in many ways have already started. i will
> > likely end up building something that works in this way anyway,
> > so please throw in suggestions, before i get carried away ;)
> >
> > ciao,
> >
> > dmotd
> >
> > On Thursday 09 April 2009 07:25:06 Hans-Christoph Steiner wrote:
> >> There are lots of good ideas worth trying.  We've talked about
> >> it a lot, we just need someone to take charge of it.  I am
> >> just too overloaded to handle pdpedia on top of everything
> >> else.  Who wants to own it?
> >>
> >> .hc
> >>
> >> On Apr 1, 2009, at 11:21 AM, Jean-Noël Montagné wrote:
> >> >> It would be good to have
> >> >> standards on how articles should be formatted and what kind
> >> >> of information should be presented.
> >> >
> >> > yes I agree. At the origin in 2006..., I have suggested to
> >> > some french PDers the following features:
> >> >
> >> >
> >> > ------------------------------------------------------------
> >> >--- ----------
> >> >
> >> > * a lexicon-dictionary about objects/externals/abstractions
> >> > ( Done)
> >> >
> >> > * a category search portal ( one of the most important
> >> > feature for pd newbies ), like in Wikipedia portal
> >> > http://fr.wikipedia.org/wiki/Wikipédia:Catégories ( to do)
> >> >
> >> > Example of category search:
> >> > PD==>Graphics==>Video==>Live==>Effects==>Blending==> pix_add
> >> > / pix_subtract /pix_diff /pix_composite/ pix_multiply/
> >> > PDP_blend ( fiction...)
> >> >
> >> > * multilingual structure as Wikipedia ( very important for
> >> > educational uses in the world where people will stay with
> >> > commercial software just for this reason ( France for
> >> > example)) (Done)
> >> >
> >> > future options, when the database will be completed enough:
> >> >
> >> > * tools or wiki tags for visualizing patches ( parsing of
> >> > the patch code to create an image of the patch, server side)
> >> > and downloading text patches from PDpedia
> >> >
> >> > * Pdpedia database embedded with PD extended ( when
> >> > completed) for offline consulting
> >> >
> >> > * in PD: a contextual help with access to the related
> >> > pdpedia page (in PD itself or online)
> >> >
> >> >
> >> > ------------------------------------------------------------
> >> >--- ----------
> >> >
> >> > About the formatting of one page, I have suggested the
> >> > rubriques:
> >> >
> >> >
> >> > ---------------------
> >> >
> >> > (from the body of the page)
> >> >
> >> > Nature of the element (object/external/abstraction/
> >> > Short Definition
> >> > Generalities (long definition)
> >> > Compatibility ( wich versions of pd)
> >> > *
> >> > Inlets
> >> > Outlets
> >> > Arguments
> >> > Messages
> >> > *
> >> > Warnings and incompatibilities
> >> > Tricks and alternative ways to do it
> >> > Examples ( expanded help file+ other examples with
> >> > pictures), links to video examples
> >> > Tutorials on this element, links to videos
> >> > Associated objects, related objects
> >> > Equivalents in similar open source softwares
> >> > *
> >> > Author(s) of the object, links
> >> > Contributors of this page.
> >> >
> >> >
> >> >
> >> > ----------
> >> >
> >> > (from the infobox)
> >> > name
> >> > ultra short description
> >> > abbreviation
> >> > library
> >> > author
> >> > developer
> >> > release version
> >> > release date
> >> > dependencies
> >> > license
> >> > website
> >> > programming language
> >> > platform (i.e Windows, Mac OS X, GNU/Linux)
> >> > operating system (i.e. Windows XP, Windows 2000, Mac OS X
> >> > 10.3, Debian, etc.)
> >> > language
> >> > data type
> >> > distribution (i.e. Pd-vanilla, pd-extended, pure:dyne, etc)
> >> > link to the code
> >> >
> >> >
> >> > ------------------------------------------------------------
> >> >--- ----------
> >> >
> >> >
> >> >
> >> >
> >> > about the work to do on the PDpedia, I have suggested to
> >> > organize PDpedia Parties:
> >> >
> >> > It's a on day or two days fiesta gathering, where PDers
> >> > decide: -first : how many objects they will document, and
> >> > wich objects ( 5 per person during 3 hours for example)
> >> > -then they document individually, in a fiesta atmosphère,
> >> > during a limited amount of time.
> >> > -then, they create collective(s) performance(s) in a
> >> > complete fiesta atmosphere
> >> >
> >> > I have also suggested that all PD teachers should give time
> >> > in their workshops for the students to document on PDpedia
> >> > the object they are discovering.
> >> >
> >> >
> >> > -----------------
> >> >
> >> > Of course, PDpedia is a long term project. There are also
> >> > many initiatives like the great FLOSSmanuals, or videopedia
> >> > to produce tutorials.
> >> >
> >> > Because of the 2500 objects/elements, the PDpedia is more on
> >> > the encyclopedic aspect.
> >> > 2500 objects and more could be completed in many languages
> >> > in five years, if the community understand how politically
> >> > important is to help newbies to use such tools with
> >> > documentation facilities. Documenting is not sometimes very
> >> > sexy, that's why I suggest to organise PDpedia parties.
> >> >
> >> > -----------------
> >> >
> >> > and yes, I agree, there is a need for some maintainers ( I
> >> > can not do it at this time), for an antispam system with a
> >> > captcha or similar stuff.
> >> >
> >> >
> >> > JN
> >> >
> >> >> 2009/3/31 Alexandre Porres <porresgmail.com>:
> >> >> > so we need :someone" to manage the system, ok, but then I
> >> >> > see
> >> >>
> >> >> that this
> >> >>
> >> >> > problem is kinda well solved, right?
> >> >> > But how do you all see the writting of articles? Is it
> >> >> > growing
> >> >>
> >> >> out well? I
> >> >>
> >> >> > believe "someone" could also direct how things are going,
> >> >> > and
> >> >>
> >> >> that a main
> >> >>
> >> >> > team could work on it by fomenting its development and
> >> >> > all... right?
> >> >>
> >> >> Something like a WikiProject on wikipedia? It would be good
> >> >> to have standards on how articles should be formatted and
> >> >> what kind of information should be presented. I see there
> >> >> has been some effort to generate a standard layout for an
> >> >> article on an object, with inlets, outlets, arguments and
> >> >> messages as separate sections; but I can't find
> >> >> a good article to serve as an example for how all articles
> >> >> should look. The best I can find is:
> >> >> http://wiki.puredata.info/en/dac~
> >> >> http://wiki.puredata.info/en/metro
> >> >> If more articles looked like this, I think pdpedia would be
> >> >> much more useful.
> >> >>
> >> >> Do we want pdpedia to just be a reference manual of
> >> >> objects, or do we also want to include design patterns such
> >> >> as the [pack 0 0 0 0 0]/[unpack 0 0 0 0 0] idiom mentioned
> >> >> elsethread, tutorials, good practices and suchlike?
> >> >
> >> > _______________________________________________
> >> > Pd-list@iem.at mailing list
> >> > UNSUBSCRIBE and account-management ->
> >> > http://lists.puredata.info/listinfo/pd-list
> >>
> >> --------------------------------------------------------------
> >>--- -----------
> >>
> >> The arc of history bends towards justice.     - Dr. Martin
> >> Luther King, Jr.
> >>
> >>
> >>
> >> _______________________________________________
> >> Pd-list@iem.at mailing list
> >> UNSUBSCRIBE and account-management ->
> >> http://lists.puredata.info/listinfo/pd-list
> >
> > _______________________________________________
> > Pd-list@iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list



_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Reply via email to