[rdfweb-dev] Re: Syntactic profiling (FOAF document formats)

Edd Dumbill edd at usefulinc.com
Thu Aug 28 09:21:12 UTC 2003


On Thu, 2003-08-28 at 08:38, Julian Bond wrote:
> As a counterpoint though take RSS 1.0. This is RDF. It quite often 
> contains properties from other vocabularies. You really ought to use an 
> RDF parser to read it. But I can extract the information I want out of 
> it and ignore the additional information using 4 or 5 Regex statements 
> or any one of 20 or so libraries written in a mish mash of regex, sgml, 
> xml parsers. And I can use the exact same code to read similar data from 
> 4 other related pure XML standards. I want to get similar ease of 
> parsing and hence similarly wide adoption of a superset of FOAF. I think 
> it's possible to do this partly because the output of Ecademy, Typepad 
> and Foaf-a-matic is so close to already having this profile.

This is a bogus argument, for a couple of reasons:

* the underlying model of basic RSS (a list of items) is drop dead
simple, your major data structure required is an array, and;

* you only get reusability benefits because the format is forked in the
first place

Using an RDF parser to process FOAF is *easier* then regex land. 
Especially if you go further than just using a parser and use a toolkit
like Redland, Drive or Jena because then your data model is done for you
as well.

Really, let's not make this harder than it should be.

These "simplifying" arguments are *very* dangerous.  Why?  Because we
risk throwing away expressivity we may well want later on when we do
some serious processing of FOAF data.  I say let's write some more
complex FOAF consuming applications and then see what we did or did not
require of the syntax.  (If we don't do this, the worst case scenario is
that we find 2 years on we needed stuff we threw out earlier and go and
have to bodge it back on to the syntax in a horrible manner.)

As a datapoint I can tell you that if I'd had to care for one second
about syntax or datamodel issues FOAFbot wouldn't have existed.  The
really hard problems were with the data.

I'd like to see us take a break from this argument and talk about issues
related to processing the data once it's parsed.  There are some
meaningful and deep issues we need to figure out.

-- Edd





More information about the foaf-dev mailing list