The goal is not at all the wider adoption of RDF. The way I am proposing atom
be seen as RDF will hopefully be completely invisible to anyone who does not
know that it is.
The point of being able to - if you will allow me the C,C++ idiom - cast an atom document to RDF will be to make it clear how to structure extensions. RDF alone does
not do this, but RDF and the AtomOWL ontology does. It does this in a way that
all Object Oriented programming languages do this: by specifying how concepts hook
together.
Take for example the following extension proposed recently
<entry>
<id>tag://sometag</id>
<geo:x>10.1</geo:x>
<geo:y>57.3</geo:y>
...
</entry>this implies the following rdf graph
_e -entry-> _E
|-id--><tag://sometag>
|-geo:x->"10.1"
|-geo:y->"57.3"which presumably would mean that _E had to be both an Entry and a geographical location, which is a very unintuitive concept, and very likely *not* what the extension author intended. It would for example meant that this object would be a different object if it had a different id.
What he probably intended was either
- That the author was at some particular location, in which case he should
probably have added attributes to the author object, through some foaf
ontology predicate.
- Or that some event the Entry is about was at some particular location. In which
case this should have gone into the <content> </content> space by using an event
ontology. Eg:
_e --content-> _event --is-a-><xyz:Event>
|---location--->_loc --is-a-><geo:location>
|--geo:x-->"10.1"
|--geo:y-->"57.3"The Object of the content predicate can accept anything (in java this would
be a method that returned an Object), so it can accept among other things an
xxx:Event.
If you look at the AtomOWL spec, you will see that among other things it is simply a specification of what types of objects a relation can take as subject and as Object.
Now we could define other mappings from xml to RDF. I have put forward some
proposals that I think could bring this much closer to the intuitions of Tim Bray
as expressed on this list. But we just don't have time. And since Atom is anyways
so close to being RDF, I think the easiest route is simply to use the work done by others. I think the price is pretty minimal. And we will end up with a format
that is extensible and even better defined than RSS1.0
Henry Story
On 17 Jan 2005, at 22:43, Bill de h�ra wrote:
Incidently the name AtomIsRDF isn't as problematic as the latent assumption - that Atom is some of kind of degenerate or special case of RDF. My opinion is that's a losing strategy if the goal is wider adoption of RDF.
