Thanks David. I take it that you would be +1 if you thought the AtomAsRDF
project were feasible. Thanks a lot for the list of problems you think
this entails.
These need to be considered one by one.
On 26 Jan 2005, at 02:20, David Powell wrote:
PaceAttributesNamespace
I'm -1 on this. It seems to be authorising a RDF users to do a transform on Atom Syntax in order to make it more RDF/XML-like.
If RDF users have to transform the content in order to interpret it as RDF/XML (which they do), then they might as well transform it to a decent RDF model which properly models the entities and properties involved in the feed. We don't need the format spec to authorize RDF users to do this - they can just do it.
The purpose of AtomAsRDF is not so much to allow RDFers to have an easy
life (we are purposely seeking minimal changes to Atom, and maximum hoop
jumping for RDFers), but to make it easy to specify a clear and powerful
extension framework for Atom. If AtomAsRDF succeeds then we can simply
build on the extensibility of RDF. Extensibility is part of the Atom Working
group charter.
I don't think that tweaking an Atom document and interpreting it as RDF/XML is going to produce a sensible RDF model.
I need skeptics to help me test my ideas. But the benefits are too big to
not at least try this out. For one it could give Atom the claim to have
dealt with the RSS wars, thereby getting the following perhaps of both camps.
So to your specific problems:
There are also a number of technical problems:
* The attribute namespace prefixing problem solved by this Pace
ok. done. Thanks. So it is +1 for the AttributesNamespace Pace ;-)
* atom:author defaulting won't be modelled sensibly
Very simple to change. And it is something that should be altered anyway. Paul Hoffman has said so on the 4th January. Dan Brickley just suggested that we need to find a way to state that the email and perhaps uri elements be inverse functional. Currently they are defined to be functional.
I will open a pace for this. The nice thing is that this is an improvement that AtomAsRDF does not absolutely need, but that would improve atom anyway.
* The xml:lang and xml:base context won't be preserved by Text
constructs and Extensions if they are modelled as RDF XML Literals.[1]
This is a more serious claim. It needs to be looked into.
* parseType="Resource" / parseType="Literal" needs to be assumed in certain places.
That is not a difficult problem to solve. It can be placed in the DTD. And be specified easily to be a hidden element in Atom.
If we try to solve all of these problems, then we are going to have to do a fairly complicated transformation that needs to be applied to produce a what could end up a quirky sub-optimal model.
As I mentioned above the point is to make it easy to explain how atom
can be extended in a well structured manner. If RDFers have to jump through
hoops that is less of a problem. It may be a problem for Atom only so far as
this may suggest to Atomers that they have designed something
unnecessarily complex.
I'd rather us make sure that we have designed the format spec well enough that it has a clear model for core elements and extensions.
Then the RDFers can come up with a clear well-designed RDF vocabulary for Atom and a mapping from Atom format to RDF (via XSLT?).
As far as the extensibility problem is concerned you would also need the following:
given an RDF graph mapped to by your xslt transformed rdf, you would need
to specify how this graph can be extended in some way and then mapped back
to produce an clearly understandable version of extended Atom, that should
easily be transformable back into your model.
And I think that AtomAsRDF is a hell of a lot simpler road to travel than that.
I've just posted this as an informal proposal on the Wiki suggesting that we let an RDF mapping should be defined outside of the format specification, and that we should avoid making this impossible:
http://intertwingly.net/wiki/pie/MinimalRdfProposal
I am trying the optimum strategy here. I think we should pursue this as far
as we can, if not all other strategies will be left as options. In any case
we are both moving in the same direction.
Henry Story http://bblfish.net/
[1] http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/#sec-Limitations
-- Dave
