[rdfweb-dev] FOAFnet and the future of FOAF in commercial systems
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
> 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.
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.
> 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