[p2p-research] Workshop on Media Ecologies: Q&A: Sam Rose

[Samuel Rose]

On Mon, Aug 24, 2009 at 6:42 PM, Nathan Cravens<knuggy at gmail.com> wrote:
> Hi Sam,
>
> You're welcome to repost any messages I send from Facebook--if that's what
> you mean.
> What questions I've left unanswered, you have either exceeded my ability to
> answer them with your answers or they are outside my knowledge areas and
> better answered by our friends on this list.
>>


Thanks, Nathan
- Show quoted text -


>> 4. Although, for open source frameworks and platforms, groupware,
>> applications, etc, We can look at how existing objects within
>> applications (like dates, identities, keywords, content objects, etc
>> etc) can be output in plural ways, under a diverse array of standard
>> output ways, to allow for wide re-use. This does not have to be done
>> by tedious extension of the native application. This is an overlooked
>> but extremely important design choice. The amount of effort that it
>> takes to extend an application that was not designed to do what you
>> are trying to do is exponentially more than creating the simple
>> mechanisms outside of the application, and giving the mechanisms
>> secure access to the data within the application. An example: Media
>> wiki was not originally designed to be a content recommendation engine
>> that works with K-means clustering algorithm. So, if you design this
>> functionality as a non-commercial service that lives outside of media
>> wiki, and adapters that let it read from and write back to media wiki,
>> the service is also available to potentially all other wiki engines as
>> well, and the amount of work to make it compatible with Media Wiki
>> software is far, far less than if the Media Wiki scripts themselves
>> have to do the heavy lifting and processing of the new functionality.
>> The external service need only be able to access data from media wiki
>> (either via a RESTful service or directly from the database) and to
>> write back to Media Wiki in a way that MW is expecting to see pages
>> and content (when it is deemed necessary to programmatically write
>> content to MW).
>
> I hope, when you have time, you describe this point more clearly. There's
> lots of unnecessary cognitive lifting involved. It sounds as if you've made
> some monumental breakthroughs and now doing your best to describe the
> practical applications the code sets intend in a short amount of time. Your
> work sounds really exciting, Sam. I look forward to seeing you and Paul
> describe how it works more clearly.


I can give one example that we are working on for people in Pittsburgh
local food systems right now.

These people want a library building application.

So, we are using Wagn as the library building interface.

So, if users want to create a way to import content into wagn that
meets a certain criteria, we create a *tform for that card type, with
a field that lets them input the external source URL, and the criteria
they want to filter for.

Then, we have a FLOWS based wrapper that interfaces directly with the
database of the wagn site. The FLOWS wrapper looks for URL's and then
talks to other FLOWS components that go out and retrieve the pieces of
content, process them and insert the content with a reference and time
stamp into the wagn wiki as a card type "external resource". The
external source can be an RSS feed, it can be an html web page, or
myriad of other resources (a wikipedia page, etc)

Our approach described in the paragraph above is not to try and make
wagn do the heavy lifting of all of that retrieval and processing.
Instead, wagn is the input of sources and then the display of copies
of imported referenced content.

Then, the users can refactor and recombine collections in wagn, then
flag those items or collections that should be published. Our database
FLOWS connector object then looks for those flags and exports that
content to a clean display that is the "library" navigation
application (possibly made with Flex, or jquery). In this case both
the wagn wiki and library navigation application are visible to the
public. But, some people don't want to dig through a wiki who's
knowledge content is always in construction. So, we make it possible
to make a stream of content coming from the wagn wiki that is
re-usable, and we make a clean navigable view out of it. This is done
programmatically. The view is embedded in the client's website. Other
entities can take this view or other views of output and republish
them elsewhere too, or make them part of archives, etc

This is one example of what we are talking about.



> I'll present a demonstration story below; one I can better understand; that
> you may want to consider applying in some way; and sooner than later; as the
> p2p foundation becomes able to fund projects like yours.
>
>>
>> We believe an approach is needed that does not care what application
>> you are using, what programming language it is in, nor even what your
>> processes are (although knowing all of this helps), but only minimally
>> requires that you output in some way that is a standard that can be
>> mapped against. That output is where Paul and myself have created a
>> standard, which is a way to abstract above the common existing
>> barriers between web software applications. We have code that works
>> with Wagn now, that will allow for this abstraction, and we'll have
>> several demos for Nov.  We have even extended this to microcontrollers
>> like Arduino, and will likely provide a demo of this, too.
>
> FLOWS in action? Even with implementation of this protocol translator, there
> will remain a great deal of work to do, but this will save a great deal of
> work toward higher level functions and for great self sufficiency.

The other thing this can do is make a new type of web service that was
maybe made to solve one problem, but is then available for multiple
other users, communities, etc
- Show quoted text -



>
>> It would be good to know the exact processes of the meeting in Nov.
>> Will this be presentation based? Or, some other format? Either way, we
>> will be able to show some actual code demonstrations connecting wagn
>> with other open source apps, services, etc. Plus, we're ready to talk
>> about the underlying theory that drove us into this direction as
>> developers.
>
> Once we know our speaker/panel line-up we'll have a detailed outline of the
> meeting. I'm doing my best to work with Phoebe and Michel to get the most
> out of this one day event. Suggestions are most welcome. ;)
>
>>
>> Thanks, Nathan, Phoebe, and Michel for putting this together. A really
>> needed meeting of minds in my opinion
>
> Its about time as far as I'm concerned. And it looks as if the time is
> right...
> I really appreciate Phoebe and Michel for performing those particular
> academic autocracies I lack tolerance in facing on my own. Phoebe is lifting
> a majority of the autocratic weight, so we might want to thank her most of
> all when giving appreciation for the workshop setting itself.
> So Sam, get your story cap on and imagine how you might apply this
> demonstration to your own work:
>
> We're at a conference taking place inside an auditorium.
> Everyone can see projected how you are accessing a graphical interface.
> You go to a search page and type the name of the event you are attending.
> A page for the event is accessed.
> You find a 'dynamic' blueprint or map of the very room you are presenting
> from.
> From this map you are able to see what objects you can access to manipulate
> in some way.
> A mobile robotic arm in set upon a desk. A sheet of paper is nearby on the
> desk.
> From the map you are able to locate the sheet of paper from your screen,
> select it, then use the cursor to fold it into a particular shape. This is a
> new design, never before virtually shaped in this way.
> After confirming your entry, the robot arm, with that information, folds the
> paper to your specifications.
> Demonstration complete.

I don't know if we'll be able to demo something like that in time for
Nov, but we can definitely show how some of it is currently possible
(assuming you already have the folding robot, the data model of the
room, and the software that enables toolpaths for folding :-) )





>
> When things of this sort become common and seamless, it is imperative that
> we make theft obsolete! That cannot be stressed enough! It is for reasons
> such as this I have described open manufacturing in a positive rather
> than neutral manners: positive in the sense that it must also render
> everything  'gratis' or free to have at no monetary cost, but also without
> sacrificing lives, our own and the ecologies that sustain us.

Well, it all boils down to who you allow to run your virtual folding
tool, of course.


> After Smári's jaw dropping presentation of Industry 2.0, I hope achieving
> such an aim does not seem so daunting.


The only things daunting about it are the software that creates the 3D
representation of the folded object. I did not see Smári's Industry
2.0 presentation, but maybe he presented some existing technology
(software and robotics) that does this already?

Also, dynamic modeling of a room would presumably be mocked up, since
not technology that I know of exists that dynamically models rooms on
the fly, and because the robotics would only need a connection to the
internet, and a piece of paper placed in the robot's working space to
accomplish the remote folding, assuming the software that lets you
build the "folded paper" model can send data across the wire to the
robot.

This demo would be an awesome display for sure. If all of the above
software exists, we could use FLOWS to make each component part of the
software talk to the other and pass data to where it needs to go in a
*standard* way.

I would think about doing what you describe above with COLLADA
https://collada.org/mediawiki/index.php/COLLADA_-_Digital_Asset_and_FX_Exchange_Schema
and maybe something like
http://www.sirikata.com/wiki/index.php?title=Main_Page  plus maybe
heeksCAD/CAM and xyz robot that could accomplish folding

Although, it seems like it would be easier to just use telesurgery
robots and cameras if you want to do remote folding! I guess it
depends on what the real goal is here.

A more practically immediately implementable example, IMO,  of what
FLOWS and open standards can do with regard to flexible fabrication
would be to allow people to store and serve multiple parts of a
"package" of CAD files, bill of materials, parametrics data, and any
other relative data about a technology, or the technologies needed to
make that technology, in a distrbuted way (like on multiple servers).
These packages could still be maintained by a specific project or
person. That project or person would really do the job of "vetting"
the contents of that package so that other people reasonably know they
can trust it.  But, the same files could live in many, many packages,
each maintained by a specific maintainer. FLOWS gives a standard way
of letting a system know that your files or data are part of a package
(or to submit for inclusion in a package). Now, you can park your
design files *anywhere*, yet they can still be part of a package.

Another practical immediate example is that you could export certain
contents of those files to be repackaged as a PDF, and even create a
print on demand book from that collection of files. You could actually
export a collection of files in any way that is possible through
existing open source libraries. A FLOWS based component could also
send out all kinds of meta data about the packages. Who is accessing
them, multiple materials sources for what the package is made of, etc