[rdfweb-dev] FOAFnet and the future of FOAF in commercial systems

Danny Ayers danny666 at virgilio.it
Fri May 7 16:47:36 UTC 2004

Julian Bond wrote:

> Danny Ayers <danny666 at virgilio.it> wrote:
>> Julian Bond wrote:
>>> Then there's datastores. There are huge amounts of code implemented 
>>> out there that could use FOAF but which are engineered on top of a 
>>> SQL datastore. Suggesting we re-engineer these to use a native RDF 
>>> data store just makes me laugh.
>> Why? Many RDF datastores use a SQL RDBMS backend, the change is more 
>> in terms of application model.
> Changing the application model in Drupal, *Nuke, phpBB and the 
> hundreds of other bits of existing code with an account system and SQL 
> also makes me laugh...

I believe in most cases it should be possible to augment existing 
systems without tearing everything up and starting again.

> We've got to face the fact that there's tons (really a lot) of 
> existing code with existing user account systems held in more or less 
> normalised SQL data tables.

This isn't necessarily a bad thing. The more normalised they are, the 
easier it will be to hook into RDF's relational structure. Worst case, 
add tables mapping primary keys to URIs.

> Requiring that these are changed in order to support a data transport 
> protocol better just ain't going to work. This is what makes current 
> FOAF a write only format.

There's more to it that a data transport protocol and format, which does 
make it more difficult. But the alternative is sticking to a relatively 
inflexible data model. If a subsystem is added to support FOAF at the 
model level, then support for an awful lot of other things comes free, 
such as RDF languages for other domains (the event/calendar stuff would 
be one obvious candidate, stuff like MusicBrainz could appeal to 
specific market sectors). Oh yes, and interoperability between those  
variant CMSs.

> It's easy (almost trivial) to export FOAF from an existing user 
> account system. It's much harder to import arbitrary FOAF into an 
> existing user account system. But then given how everyone reinvents 
> the wheel for every new system maybe it would be hard no matter what 
> interchange format we used[1].

Well yes, that's a fair point. But I had a look through some of the 
leading PHP CMSs not long ago, and they were virtually 
indistinguishable. If someone wanted to build a system (CMS, BBS, YASN) 
with the intention of attraction users, then consideration of a 
different wheel design would make sense. Just outside the Drupal- phpBB- 
Frienster- clone box is a whole ready-designed architecture for doing 
new stuff.  It's possible to look at FOAF support as an uphill struggle, 
but looked at another way it's low-hanging fruit. My prediction is that 
within the next year or so one or two companies will be cashing in on 
that big time, and they won't be using much more than what's on the 
table today. Their advantage will be gained from flexibility in adopting 
new systems (most likely in parallel with existing systems), not trying 
to shoehorn new material into inflexible structures.

> [1]You'd think by now that we'd all know how to store international 
> names, addresses, phone numbers, but apparently not. But then you'd 
> also think we'd have consistent date formats after ~2000 years of the 
> current system.
Life's rich tapestry is a bugger for programmers ;-)



More information about the foaf-dev mailing list