Semantics permathread (was Re: Categories for atom?)

[Mark Pilgrim <f8dy@xxxxxxxxxxxxxxxx>]

> This approach does seem the logical one, though it highlights a real glaring
> omission - nothing is said about how the element from another namespace is
> interpreted. In this case its clear that the contents of dc:subject refer to
> its parent element, but that's a human best-guess, nothing in the Atom (or
> DC) spec covers this.

Permathread, here we come...

XML is hierarchical.  If I put a <dc:subject> element within an <entry> 
element, I'm saying "this is the category of this entry".  If I put 
multiple <dc:subject> elements within an <entry>, I'm saying "these are 
the categories of this entry".

If I wanted the <dc:subject> to apply to something else, I'd put it 
somewhere else in the XML document.

In RDF-speak, in XML the subject is the parent element, the object is 
the value of the child element, and the predicate is "has" + the name of 
the child element.

<entry>
  <title>Foo</title>
  <dc:subject>Random</dc:subject>
</entry>

means "This entry has title 'Foo'.  This entry has subject 'Random'."

This has proven to be enough semantics for pretty much every widely 
adopted real-world application, um, ever.  Including most FOAF files 
I've seen in the wild, which contain such simple semantics that they 
could just as easily be represented as key-value pairs in an INI file.

Heading off the inevitable "oh but it's really all about the data model 
and there's this edge case that can only be expressed if the data model 
is RDF and you might want to do that..."  Well, we don't.  We talked 
about it on the wiki ages ago, and the overwhelming consensus (even from 
die-hard RDF advocates like Norman Walsh) was that RDF is overkill for 
this application.

http://www.intertwingly.net/wiki/pie/MultipleSyntaxDiscussion
http://www.intertwingly.net/wiki/pie/RdfAndEcho

-Mark