Re: Running code

On 18/12/06, Kjetil Kjernsmo <kjetilk@opera.com> wrote:

[...]

> I think that at this point, running code is the most important outreach
> we can do.

Absolutely.

The long tail still thinks that semweb is an academic
> exercise, and they will not be awaken unless there is applications that
> actually does something practical. More theory will not have any effect
> on them, I believe.
>
> I think we should address those who are most likely to write running
> code. Writing code is not within the scope of this group, I guess, but
> to address the many web developers, I think finding ways to get running
> code is the most important thing we can do to attract attention.

Agreed. But although writing code may be out of scope, I think given
the libraries (and vocabularies) available, much of the hard work's
already been done. What's needed are:

1. some compelling, non-trivial but most importantly not overambitious
application scenarios
2. reasonably stable hosting
3. a bucketload of glue

> I have two concrete proposals that I believe could have a good effect,
> but recruiting coders to an idea is a delicate business. Good coders
> prefer not to have an finished idea thrown at them with a "do this"
> attached. Making tools available and adding functionality that
> stimulates creativity is better.

I'm only an average coder, so please feel free to pass on your proposals ;-)

> However, I think that many semweb-interested developers recognize the
> need to come together and get a community commitment towards a small
> number of projects to get some applications up and running. To get
> people talking and get consensus around building something would be
> important.

Right.

> Finally, we must also acknowledge that quite a few people have made an
> honest attempt at building a semwebby system but failed. Personally, I
> know a few, and there are two problems they usually quote: 1) That the
> free software tools we have do not perform well enough on larger scales
> (free software tools are critical since they represent a low-risk
> entry),

Performance & scale are certainly issues, but for showcase purposes
I'd say the pragmatic solution is to pick apps that don't need massive
data/performance, and/or ones which distribute the workload.

 and 2) validation of data, e.g. if you get user input, can you
> ensure within a pure-RDF framework that you the data your application
> needs for operation.

Ok, I think I'd attach that issue to the bucketload of glue.

This has often lead people to dump RDF in favor of
> custom XML. I think it is important for the community to address the
> concerns of those who try and fail in a timely manner.

Right. A case that was interesting was a year or two when some folks
(associated with LiveJournal?) were looking into doing more with FOAF.
Unfortunately the available parser(s) etc for PHP at the time were way
too slow. If I remember correctly RDF was dumped in favour of straight
XML, but the situation was enough to trigger community effort to make
the PHP libs significantly more performant.

Cheers,
Danny.


-- 

http://dannyayers.com

Received on Monday, 18 December 2006 13:26:56 UTC