Thanks for the reply, Sam.
I think the misunderstanding has mostly to do with the fact that we have similar
but slightly different aims. We should try to clearly establish our respective aims
and find the points we have in common, so that we can agree to solve the points
we have in common quickly and easily.
On 27 Jan 2005, at 03:39, Sam Ruby wrote:
Henry Story wrote:On 26 Jan 2005, at 15:03, Sam Ruby wrote:[...]I think your assertion is wrong. If they are consuming or producing extended Atom [1]
But, now lets examine the statement proposed in PaceAttributeNamespace. It essentially alerts producers of something that that they need to be aware of. Now a quesion: what do they need do different with the knowledge that the RDF mapping does this?
I would assert the answer to this question is nothing. Meaning that this particular statement is not needed. Again, no issue with the mapping. No issue with describing the mapping alongside with the actual mapping.
they will know exactly what these extensions are referring to. It won't
affect in the least consumers of simple, non extended Atom, but it will greatly
help consumers and producers of extended atom.
Now if you don't care about making their lives easier, then you have nothing
to worry about in this pace. If you do, like I and many others, then this will
be very helpful.
It seems to me that you are both misunderstanding and mischaracterizing what I am saying. Furthermore, in other emails, I sense a confusion between RDF (which is a model) and RDF/XML (which is a syntax).
No worry. I think we all know the difference there, but the language does lend itself
to confusion.
I am in favor of AtomAsRDF (as a way to model this data). I am opposed to AtomAsRDFXML (as a syntax for expressing this model).
Ok. I am in favor of AtomAsRDF(Model) too. But I am trying to go a little further
to AtomAsRDFXML (as you put it) because
- The spec can very nearly already be interpreted that way
- defining another mapping from xml to RDF, though possible,
is a lot of work, and we just don't have the time
- it will allow for the easiest way to explain extensibility of AtomSo though I think (and I have recently myself tried out some ideas on this subject)
there may be some general mapping rule from xml to rdf that are much closer to the general users intuitions about xml, I think that when the xml is written as atom
currently (nearly) is, we have something that does map to a graph and that will map
to the same graph than any more intuitive mapping than rdf/xml would.
If anybody is up to the task, I am for inclusion of prose into the
standard describing how one is to interpret Atom feeds as RDF. Any such
mechanism that accomplishes this will, by necessity, need to specify
what namespace is used in the URIs used to define relationships.
Well I liked your idea of adding a special section to the spec on how to interpret atom as rdf/xml, perhaps as part of the extensibility section. My feeling is that would be best if it explains how atom can be seen to be rdf/xml, because then explaining extensibility will be very easy:
"any atom document with foreign name spaced attributes or elements must also be an rdf/xml document when so interpreted"
And we then leave the complexity of that statement to the other specs out there.
PaceAttributeNamespace does not do that. All it says is is that a given
namespace may be used. For what purpose such a statement is made is
entirely unclear.
By contrast, a precise statement to the effect of how RDF aware tools MUST interpret Atom feeds if they are to interoperate is both clear and useful.
Ok. Well I think we are really thinking very similar thoughts here.
I would just add that we should try to see if the RDF/XML interpretation
of Atom works out, because that will vastly reduce the amount of work we
need to do in explaining the interpretation. ("interpretation" is an
excellent word!)Henry Story
- Sam Ruby
