Not if you’re using external entities in your XML source files (all your content is in XML, right?). Just update your entity reference and run your site generation script again. That’s how I do on my blog, anyway.

RDF is not a format… it’s a data model. The syntax can be XML or ***anything else***.

N3 is not unreadable and it’s RDF.

Didn’t God give us XML and XML parsers so that we didn’t have to use tedious regular expressions? And aren’t regular expressions the one thing in the world that’s harder than RDF!

Insofar as God giving us XML (and parsers) to avoid regular expressions, that’s a bit like discounting the value of modern automobile, since we now have modern jetliners. Different tools, different uses. One of the most pervasive, immature attitudes across the ‘Net is that there is a ONE TRUE way to do things. The trick (and maturity) comes in knowing when to use the right tools for the job at hand. So long as XFN stays true to its purpose — a simple annotation — there is nothing wrong with a simple format; XML loses value as a format when you only have a _very_ simplistic data model to express.

With regard to the question about how “difficult” RDF is to learn, I would note that in my personal experience it took me a day to get a basic grasp on regexes and practically apply them. RDF, I studied for weeks before I even started to understand what to do with it, much less apply it anywhere. But that’s just me.

Bill Kearney suggested that programmers need to stop thinking about readability, and start using good tools. The problem with that (circular) argument is that someone, somewhere, has to WRITE the tools. The more complex a format is (such as RDF), the longer it takes to get bootstrapped, since the population capable of READING and understanding the format and it’s applicability is dramatically restricted. Of course this gets into social dynamics, and I would note that populations capable of understanding highly complex formats are typically disinclined to write tools to help others — they’d rather use of the power of the format than spend time explaining it.

IMHO, of course.

http://www.ldodds.com/foaf/foaf-a-matic

…but I doubt she could create an HTML link. (And yes, she’d still have to work out how to publish her FOAF file afterwards, but that’s what geek sons are for!). Additional notes/corrections on XFN and FOAF here:

http://www.ldodds.com/blog/archives/000105.html

Now, fast forward to now and you’d find it utterly ridiculous to do it that way. The tools for drawing pictures do all the dirty work for you. You *NEVER* read the file that contains the GIF, PNG or heck, even SVG or PostScript! At least not unless you a programmer.

So the same analogy applies here. All the programmer types are whining about ‘view source’ because they’re using shitty tools. Stop using (or start developing) tools that don’t let you SEE the DATA in ways it’s best represented.

But please, spare us this continued nonsensical arguments about human readability. They’re just wrong.

We might have represented values as a set of nested elements, and thus followed general XML practices, but that would have had two very significant drawbacks. The first is that it would make the format less human-readable, and that’s a crucial point. It was very important to us that an XFN value be human-readable in a glance, and understandable even by people who have never seen XFN before. The second is that if we’d represented XFN information as elements within the link, it couldn’t have been used in valid HTML documents. That was also very important, because while XML may be the future, HTML is now, and we wanted something that would work in current documents as well as be easily used in future documents.

Besides, like Matt, I can’t think of too many things that are easier to parse than a space-separated list, and I haven’t been a programmer since the halcyon days of Turbo PASCAL 4.5. (Before Mosaic, that was.) I’m not familiar with good XML design practice when it comes to attribute values, I admit– could you point us to some resources that explain what good and bad XML design practice is, and why the good things are good and the bad things are bad? I’d find such information useful for the future.

Didn’t God give us XML and XML parsers so that we didn’t have to use tedious regular expressions? And aren’t regular expressions the one thing in the world that’s harder than RDF! Regarding multiple values in attributes, if you want to ignore good XML design practice then so be it. If you want to make it harder to parse XFN then go ahead …

Victor, I understand RDF syntax, how it works, and its purpose in the larger view of machine-parsable semantic richness, but it’s complicated. Way too hard. My mom could do XFN by hand, she wouldn’t know where to begin with FOAF. However there’s no reason you can’t do both. If you have invested the time and effort in making a good FOAF file, XFN should be a breeze. And what’s less parsable about a space-seperated string? I can grab all the XFN values from a page with one line of regex and maybe an explode statement.

For more than a year now (most over a year ago now), I’ve been analyzing the markup of blogs, and occasionally writing posts explaining how I think their markup could easily be made simpler, smaller and more semantic.