[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rdf in atom
On 02/07/2008, at 6:58 AM, Bill de hOra wrote:
1: QNames in content:
"The at:map element indicates how an element in a given context
(either feed or entry, depending on use) maps to RDF statements.
Its content MUST be an XML QName, and indicates the element that is
being mapped."
that's more or less a bug from my pov.
I'm not a big fan either. I think this is the part of the spec that
needs most discussion; e.g., I can imagine that XPath may be more
useful ultimately, given things like atom:author. The counter-argument
to that is that keeping it simple encourages simple Atom extensions,
which are IMO good.
Realise the intent here wasn't to enable a complete mapping of an Atom
document to RDF, but rather to allow Atom to be used to move some
statements around. The mapping section of the spec isn't intended to
be fully capable of extracting statements from random parts of the
doc, but rather to avoid needless duplication (e.g., with dates, etc.)
where it's low-hanging fruit.
2: Mapping aren't declared out of band; instead the ID mixes layers
(data and binding rules).
Separating data and binding is a good idea in code; I'm less convinced
it is when you're trying to make that data/binding package
interoperable across administrative domains.
3: it doesn't work for person constructs unless QNames in content +
XPath is an option.
See #1.
4: I'm skeptical a new binding language is needed on top of Atom/RDF/
Owl/Skos.
Noted.
5: I think most of what at:* achieves can be done through attribute
annotation (ie a variant on architectural forms):
<atom:title owl:SameAs="http://dc.org/#title";>atom:title</atom:title>
thus avoiding 1 and 4 above.
I looked at this, but adding attributes to existing Atom elements
seemed dicey; the spec isn't crystal-clear about it, and some
implementations don't support it IIRC. It would be interesting to get
the Atom world's take on this.
--
Mark Nottingham http://www.mnot.net/