Danny Ayers Reto Bachmann-Gmuer 2005-10-23 Henry Story Atom Syndication Ontology The AtomOWL ontology is inspired from the work done by the atom working group. This ontology is working off the spec draft-ietf-atompub-format-11.txt published at http://www.ietf.org/internet-drafts/. I will call this atom11 in this ontology. The AtomOWL ontology uses as much as possible the same terms as the format there to make the relation easy to understand. The AtomOWL name space is slightly different from the atom namespace [see post http://www.imc.org/atom-syntax/mail-archive/msg16476.html]. But this is a good thing as it helps distinguish the ontology from the atom11 serialisation. see 4.2.7.2.1 of atom11. The object points to an alternate version of the subject alternate relation see 4.2.7.2.4 of atom11. The object is a related resource that is potentially large in size and requires special handling. enclosure relation see 4.2.7.2.2 of atom11. The object points to a related version of the subject. So if the subject is a Entry the object might be a resource with an html representation of that entry. related see 4.2.7.2.3 of atom11. The object is equivalent to the subject. self relation is this owl:sameAs? or some other well known identity relation? see 4.2.7.2.5 of atom11. The object provided a source of the information found in the subject. via relation see 4.2.2 of atom11. A Category Type a category The construct with term and scheme looks very much like a URI-Ref used in RDF. Isn't this just any rdfs:Resource? Maybe skos:Concept could be used as range of :category. see section 4.1.3 in atom11. content class see section 4.1.2 of the atom11 spec Identifier for Entry Entry Id Container for feed metadata. Identifier for Feed things. Feed Id Union of the Feed and Entry class. Simplifies writing the ontology. 1 see section 4.2.4 of atom11 spec. Generator for the Feed. It has many properties in common with :Person Generator of feed is this an instance of the piece of software or the program itself? which is the agent Entries and Feeds have ids that relate the different instances. The idea of using a domain of InformationResource is from Reto Backman-Gmur. Comments welcome. It introduces the webarch ontology. does webarch:InformationResource have to be dereferenceable? atom11 speaks in terms of IRI's which are not integrated properly into RDF yet. This means that some information may be lost in the process of converting from atom11 to atomOWL see section 4.2.7 of atom11 spec. It turns out that the link is really just a reified statement in order to add some information, most notably a title to a link. See the rules at the end. Link Class see section 3.2 of atom11 spec. Person class 1 text/plain Metadata about the state of a resource with given :id at an :updated time. 1 1 See section 4.2.1 atom11 spec. author See section 4.2.2. A category with which the conainer is associated. See section 4.1.3 of atom11 spec. The content of an Entry content See section 4.2.3 of atom11 spec. Someone who contributed to the Version of the Container. contributor A comment by Danny Ayers see 3.2.3 of atom11. A mailbox of the Person email address The feed contains the given Entry. See 4.1.1 of atom11 An entry of a Feed See section 4.1.1 of atom11 spec. The id of the feed. feed id we don't really need this relation. I just want to express that the id of a Feed, should be a FeedId, and not an EntryId. This is because there are some properties that are true of FeedId's (They have update relations to entries for example see section 4.2.4 of atom11. The generator of the object The domain should really just be :Version. I don't see why Entries can't have an generator too (especially as atom:entry can be a top level content). see 4.2.4 of atom11. Indicates the version of the Generator version see 4.2.7.1 of atom11. hyperlink reference see 4.2.5 of atom11. An icon associated with the object icon The domain should really just be :Version. I don't see why Entries can't have an icon. See section 4.2.6 atom11 spec. All Versions with the same id can be considered to be versions of the resource identified by the id. Hence the inverse :version relationship. id see 4.2.2.3 of atom11. A Human readable label for display. label Should this be functional? Given the language sensitivity of the label see 4.2.7.4 of atom11. The language of the representation. language see 4.2.7.6 of atom11. The length in bytes of the representation. length in bytes See section 4.2.7 of atom11 spec. A link associated with the container. If the link is unreified, we have a relation from the container to some resource link the title of the link as defined by atom11 4.2.7.5. name of link We could not call this relation :title because of clash with entry and feed title see 4.2.8 of atom11. An icon associated with the object logo The domain should really just be :Version. I don't see why Entries can't have a logo too. see 3.2.1 of atom11. A human readable name for the Person. see 4.2.4 of atom11. A name for the Generator. name See section 4.2.9 of atom11 spec. A date associated with an event early in the lifecyle of the subject. publication date see 4.2.7.2 of atom11. The relationship type. The relationship type is a property that relates as object the relation type A comment by Reto Bachmann-Gmuer See section 4.2.10 of atom11 spec. Rights held over a Version. rights see 4.2.2.2 of atom11. Identifies a categorization scheme. catgegorization scheme See section 4.2.11 of atom11 spec. The source feed where the entry was found source feed a source of the representation source the inverse of the :link relation, not specified in atom11, but added here for convenience the object of the link see section 4.2.12 of atom11. Subtitle of the feed. subtitle See section 4.2.13 of atom11 spec. A summary of the content of the Entry summary see 4.2.2.1 of atom11. Identifies the category term should specify that there is exactly one term See section 4.2.14. Title of a container title Reto argues that a Title should have any content attached to it. One should for example allow picture for people who can't read or audio titles for people who cannot write. This would of course make the semantics be a lot more lax that the atom11 syntax allows. see 4.2.7.3 of atom11. The mime type of the representation. mime type The feed has published the given entry An entry of a Feed See section 4.2.15 of atom11 spec. Indicates the most recent instant in time when a resource ID was modified in a way the publisher considers significant. Therefore, not all modifications necessarily result in a changed atom:updated value. updated see 3.2.2 of atom11. A uri associated the Person see 4.2.4 of atom11. A uri associated the Generator a uri the uri with subject :Agent and :Generator are really the same relation this is the content as a string bits of the representation How are the bits encoded in a xsd:string? the inverse of the id relation. The state of an id is always a :Version version of an id resource