see section 4. of Atom Spec [[note: it would be more in sync with convention of class names for feed to be capitalised to "Feed"]]
see section 4.2.6 for Head ans section 5.5 for Element
see section 4.2.8 for Head and section 5.6 for Entry
see section 4.2.5 for Head and section 5.4 for Entry
see section 3.5.3 for link href and section 3.4.1 for Service href
see section 4.2.11 [[ the range of this property should be a TEXT thing which sounds like a union of 3 different types of literals ]]
see section 4.2.9 [[ this represents the software agent string I can't find a way to get this to work out quite right. The content of this element is meant to be the content of the agent ]]
see section 5.10.2 [[should this be inverse functional? don't know yet ]]
see section 4.2.1 [[ This should point to a new TEXT literal type, which I can't create easily in Protégé, but which might be possible in RDF ]] [[ There is a clash with title from the link construct which can only be of type string ]]
see section 4.2.12 for Head and section 5.7 for Entry
see section 5.9 [[This is a TEXT construct, need to find the literal that goes with this ]]
see section 4.1for feed and section 4.2.9 for Generator
see section 3.2.1 [[it is not clear why one should reduce the number of names a person has to one]]
see section 3.2.3 [[this definitively would be better associated with a mailto:.. uri and be inverse functional. IE one should conclude that if two atom person constructs are related to the same mailto uri, thery are the same person]] [[ it also seems a pitty to restrict the number of emails a person can have to one]]
see 3.5.2 for Link and 5.10.1 for Content. [[I am not absolutely sure these are the same properties, though they are very similar ]]
see section 3.2.2 for Person and section 4.2.9 for Generator [[ note that it may be much more interesting to associate an inverse funtional uri with a person. This means that the person is identified exactly by that uri. One can then use the URI to find other information on the web corresponding to that uri. But then perhaps it would be better if uri were defined a little more presicely]]