primer notes
0 views
Skip to first unread message
Henry Story
Nov 18, 2005, 10:01:35 AM11/18/05
to atom...@googlegroups.com, bloged
How can I start explaining the current atom-owl draft onotlogy [1]?
Philosophical overview
----------------------
First perhaps some philosophical overview. The idea of this ontology
is for it to be a basis to move towards the accepted standard
ontology of the atom-syntax [2], that will be placed in the name atom
namespace location
http://www.w3.org/2005/Atom
For this to be possible we have to have an ontology that is really
faithful to the syntax, and that is acceptable without difficulty to
the atom working group. It should mold itself well around the
expectations of the atom-syntax folks.
Why do we need an atom semantics? Because this will help make
standard sparql end points possible. http://www.intertwingly.net/wiki/
pie/PaceSparqlLink
It will also help make make decisions on atom extensions in the future.
And it used to be part of the atom charter.
Introduction
------------
To achieve the above we have used as much as possible (except for a
couple of occasions when we found that there were name clashes) to
use the exact same term as are used in the atom syntax document. Each
term introduced in the atom-owl ontology is explained with reference
to the syntax spec.
For example:
:id a owl:FunctionalProperty,
owl:ObjectProperty;
rdfs:label "id"@en;
rdfs:comment "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."@en;
rdfs:domain :Version;
rdfs:range :Id .
We have avoided the temptation to do "better" than the work of the
atom-syntax, by using names to mean things that are slightly
different from those used in the atom syntax. They spent over 2 years
working on that document, it is now very well understood, and we want
to work with the intuitions that working group has helped create.
An Example
----------
So the best way to show this is to start with an example. The first
example from the atom-spec is the following mini feed:
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Example Feed</title>
<link href="http://example.org/"/>
<updated>2003-12-13T18:30:02Z</updated>
<author>
<name>John Doe</name>
</author>
<id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
<entry>
<title>Atom-Powered Robots Run Amok</title>
<link href="http://example.org/2003/12/13/atom03"/>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<summary>Some text.</summary>
</entry>
</feed>
This can be written in atom owl in N3 as [3]:
[ a :Feed, :Version;
:title [ :value "Example Feed";
:type "text/plain" ];
:link [ :href <http://example.org/>;
:rel iana:alternate ];
:updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
:author [ :name "John Doe" ];
:id <urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6>;
:entry [ a :Entry, :Version;
:title [ :value "Atom-Powered Robots Run Amok";
:type "text/plain" ];
:link [ :href <http://example.org/2003/12/13/atom03>;
:rel iana:alternate ];
:id <urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a>;
:updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
:summary [ :value "some text";
:type "text/plain" ]
];
] .
Notice how faithful the N3 is to the atom-syntax. The only thing that
is new here is the :Version class, and it is not really needed. Since
a :Feed and :Entry are both subclasses of :Version. I am not at all
wedded to the :Version name. It just helps a little to avoid the trap
explained in a recent post to this list of thinking of an Entry as
its id [4], which is a trap we have all fallen into when initially
creating an ontology for atom.
So an <entry> in atom-syntax is a blank node in N3 that has a
functional id property. That is if different :Entry things have the
same id, they are considered to be different versions of each other.
Clearly a database that wishes to store atom may not want to be as
document centric as the above N3. The above is very document centric
because the :entry relation is between a :Feed (:Version) and
an :Entry. Since :Feeds can be linked together in lists via the soon
to be standardised iana:next, iana:previous, ... etc link relation
types [5], this means that our entries are associated to
different :Feed nodes which seems a little arbitrary, especially
since one could create any number of :Feed documents, with more or
less entries depending on the capabilities of the client. It would
clearly dramatically reduce the number of relations in a database if
instead of relating a :Feed to an :Entry one were to relate
the :Entries to the :FeedId.
This is no problem. The above graph implies it, because of the rule:
{ ?feed a :Feed;
:id ?feedId;
:entry ?entry . } => { ?feedId :update ?entry } .
We have an :update relation between a :FeedId and a :Entry. In
english an entry is an update in a feed. (Better nomenclature is
clearly possible. I am not stuck on this at all)
So give the above rule I would probably put the following relations
in my database [6]:
<urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6> a :FeedId;
:version [ a :Feed, :Version;
= _:state1;
:title [ :string "Example Feed";
:type "text/simple" ];
iana:alternate <http://example.org/>;
:updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
:author [ :name "John Doe" ];
];
:update [ a :Entry, :Version;
:title [ :value "Atom-Powered Robots Run Amok";
:type "text/plain" ];
iana:alternate <http://example.org/2003/12/13/atom03>;
:id [ = <urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a>;
a :EntryId ];
:updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
:summary [ :value "some text";
:type "text/simple" ];
:source _:state1;
] .
Here we have rooted the tree at the :FeedId, instead of rooting it at
a :Feed. The relation between the :Entry and the :Feed is now kept in
the :source relations ":source _:state1". A database or agent may or
may not wish to keep this information.
Now there is one more thing that has happened in the above
transformation that I'd better mention quickly. The :link relations
have disappeared and been replaced by something else. We used to have
[ a :Entry;
:link [ :href <http://example.org/2003/12/13/atom03>;
:rel iana:alternate ]
] .
And now we have
[ a :Entry
iana:alternate <http://example.org/2003/12/13/atom03>
] .
We have reduced three relations down to 1.
How do we do this?
Well first I have defined a :Link object to be a subclass of
rdfs:Statement
:Link a owl:Class;
rdfs:label "Link Class"@en;
rdfs:comment "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. "@en;
rdfs:subClassOf rdf:Statement .
And then I have mapped the atom link relations to the rdfs:Statement
relations
:subject a owl:ObjectProperty;
rdfs:label "the object of the link"@en;
rdfs:comment "the inverse of the :link relation, not
specified in atom11, but added here for convenience"@en;
rdfs:subPropertyOf rdf:subject;
owl:inverseOf :link .
:rel a owl:ObjectProperty;
rdfs:label "relation type"@en;
rdfs:comment "see 4.2.7.2 of atom11. The relationship type.
The relationship type is a property that relates as object the "@en;
rdfs:subPropertyOf rdf:predicate;
rdfs:domain :Link;
rdfs:range :RelationType .
:href a owl:ObjectProperty,
owl:FunctionalProperty;
rdfs:label "hyperlink reference"@en;
rdfs:comment "see 4.2.7.1 of atom11."@en;
rdfs:subPropertyOf rdf:object;
rdfs:domain :Link;
rdfs:range webarch:InformationResource .
Finally I have added a rule
{ ?link :subject ?state;
:rel ?rel;
:href ?obj . } => { ?state ?rel ?obj . } .
which states in english that a :Link is a :Statement which always
entails the statement it reifies. This is very nice for databases
that do not wish to keep other metadata that is very document centric
such as "title" information. It also gives a good explanation of what
a :Link really is, I think. We know understand that when we say that
an Entry has an iana:alternate link, this is just to say that the
entry has an iana:alternate relation to some resource.
This should provide a good enough initial overview of the semantics.
Please please do feel free to ask questions. I really need feedback
to help me work out the details of this, so that we can propose this
as a starting point for W3C standardization.
Henry
[1] http://bblfish.net/work/atom-owl/2005-10-23/
[2] http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-11.txt
[3] http://bblfish.net/work/atom-owl/2005-10-23/example-1.n3
[4] http://groups.google.com/group/atom-owl/browse_frm/thread/
51d2abcfcfba3a33/2b8908b98402e251#2b8908b98402e251
[5] http://www.imc.org/atom-syntax/mail-archive/msg17431.html
[6] http://bblfish.net/work/atom-owl/2005-10-23/example-1-v3.n3
Philosophical overview
----------------------
First perhaps some philosophical overview. The idea of this ontology
is for it to be a basis to move towards the accepted standard
ontology of the atom-syntax [2], that will be placed in the name atom
namespace location
http://www.w3.org/2005/Atom
For this to be possible we have to have an ontology that is really
faithful to the syntax, and that is acceptable without difficulty to
the atom working group. It should mold itself well around the
expectations of the atom-syntax folks.
Why do we need an atom semantics? Because this will help make
standard sparql end points possible. http://www.intertwingly.net/wiki/
pie/PaceSparqlLink
It will also help make make decisions on atom extensions in the future.
And it used to be part of the atom charter.
Introduction
------------
To achieve the above we have used as much as possible (except for a
couple of occasions when we found that there were name clashes) to
use the exact same term as are used in the atom syntax document. Each
term introduced in the atom-owl ontology is explained with reference
to the syntax spec.
For example:
:id a owl:FunctionalProperty,
owl:ObjectProperty;
rdfs:label "id"@en;
rdfs:comment "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."@en;
rdfs:domain :Version;
rdfs:range :Id .
We have avoided the temptation to do "better" than the work of the
atom-syntax, by using names to mean things that are slightly
different from those used in the atom syntax. They spent over 2 years
working on that document, it is now very well understood, and we want
to work with the intuitions that working group has helped create.
An Example
----------
So the best way to show this is to start with an example. The first
example from the atom-spec is the following mini feed:
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Example Feed</title>
<link href="http://example.org/"/>
<updated>2003-12-13T18:30:02Z</updated>
<author>
<name>John Doe</name>
</author>
<id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
<entry>
<title>Atom-Powered Robots Run Amok</title>
<link href="http://example.org/2003/12/13/atom03"/>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<summary>Some text.</summary>
</entry>
</feed>
This can be written in atom owl in N3 as [3]:
[ a :Feed, :Version;
:title [ :value "Example Feed";
:type "text/plain" ];
:link [ :href <http://example.org/>;
:rel iana:alternate ];
:updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
:author [ :name "John Doe" ];
:id <urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6>;
:entry [ a :Entry, :Version;
:title [ :value "Atom-Powered Robots Run Amok";
:type "text/plain" ];
:link [ :href <http://example.org/2003/12/13/atom03>;
:rel iana:alternate ];
:id <urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a>;
:updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
:summary [ :value "some text";
:type "text/plain" ]
];
] .
Notice how faithful the N3 is to the atom-syntax. The only thing that
is new here is the :Version class, and it is not really needed. Since
a :Feed and :Entry are both subclasses of :Version. I am not at all
wedded to the :Version name. It just helps a little to avoid the trap
explained in a recent post to this list of thinking of an Entry as
its id [4], which is a trap we have all fallen into when initially
creating an ontology for atom.
So an <entry> in atom-syntax is a blank node in N3 that has a
functional id property. That is if different :Entry things have the
same id, they are considered to be different versions of each other.
Clearly a database that wishes to store atom may not want to be as
document centric as the above N3. The above is very document centric
because the :entry relation is between a :Feed (:Version) and
an :Entry. Since :Feeds can be linked together in lists via the soon
to be standardised iana:next, iana:previous, ... etc link relation
types [5], this means that our entries are associated to
different :Feed nodes which seems a little arbitrary, especially
since one could create any number of :Feed documents, with more or
less entries depending on the capabilities of the client. It would
clearly dramatically reduce the number of relations in a database if
instead of relating a :Feed to an :Entry one were to relate
the :Entries to the :FeedId.
This is no problem. The above graph implies it, because of the rule:
{ ?feed a :Feed;
:id ?feedId;
:entry ?entry . } => { ?feedId :update ?entry } .
We have an :update relation between a :FeedId and a :Entry. In
english an entry is an update in a feed. (Better nomenclature is
clearly possible. I am not stuck on this at all)
So give the above rule I would probably put the following relations
in my database [6]:
<urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6> a :FeedId;
:version [ a :Feed, :Version;
= _:state1;
:title [ :string "Example Feed";
:type "text/simple" ];
iana:alternate <http://example.org/>;
:updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
:author [ :name "John Doe" ];
];
:update [ a :Entry, :Version;
:title [ :value "Atom-Powered Robots Run Amok";
:type "text/plain" ];
iana:alternate <http://example.org/2003/12/13/atom03>;
:id [ = <urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a>;
a :EntryId ];
:updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
:summary [ :value "some text";
:type "text/simple" ];
:source _:state1;
] .
Here we have rooted the tree at the :FeedId, instead of rooting it at
a :Feed. The relation between the :Entry and the :Feed is now kept in
the :source relations ":source _:state1". A database or agent may or
may not wish to keep this information.
Now there is one more thing that has happened in the above
transformation that I'd better mention quickly. The :link relations
have disappeared and been replaced by something else. We used to have
[ a :Entry;
:link [ :href <http://example.org/2003/12/13/atom03>;
:rel iana:alternate ]
] .
And now we have
[ a :Entry
iana:alternate <http://example.org/2003/12/13/atom03>
] .
We have reduced three relations down to 1.
How do we do this?
Well first I have defined a :Link object to be a subclass of
rdfs:Statement
:Link a owl:Class;
rdfs:label "Link Class"@en;
rdfs:comment "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. "@en;
rdfs:subClassOf rdf:Statement .
And then I have mapped the atom link relations to the rdfs:Statement
relations
:subject a owl:ObjectProperty;
rdfs:label "the object of the link"@en;
rdfs:comment "the inverse of the :link relation, not
specified in atom11, but added here for convenience"@en;
rdfs:subPropertyOf rdf:subject;
owl:inverseOf :link .
:rel a owl:ObjectProperty;
rdfs:label "relation type"@en;
rdfs:comment "see 4.2.7.2 of atom11. The relationship type.
The relationship type is a property that relates as object the "@en;
rdfs:subPropertyOf rdf:predicate;
rdfs:domain :Link;
rdfs:range :RelationType .
:href a owl:ObjectProperty,
owl:FunctionalProperty;
rdfs:label "hyperlink reference"@en;
rdfs:comment "see 4.2.7.1 of atom11."@en;
rdfs:subPropertyOf rdf:object;
rdfs:domain :Link;
rdfs:range webarch:InformationResource .
Finally I have added a rule
{ ?link :subject ?state;
:rel ?rel;
:href ?obj . } => { ?state ?rel ?obj . } .
which states in english that a :Link is a :Statement which always
entails the statement it reifies. This is very nice for databases
that do not wish to keep other metadata that is very document centric
such as "title" information. It also gives a good explanation of what
a :Link really is, I think. We know understand that when we say that
an Entry has an iana:alternate link, this is just to say that the
entry has an iana:alternate relation to some resource.
This should provide a good enough initial overview of the semantics.
Please please do feel free to ask questions. I really need feedback
to help me work out the details of this, so that we can propose this
as a starting point for W3C standardization.
Henry
[1] http://bblfish.net/work/atom-owl/2005-10-23/
[2] http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-11.txt
[3] http://bblfish.net/work/atom-owl/2005-10-23/example-1.n3
[4] http://groups.google.com/group/atom-owl/browse_frm/thread/
51d2abcfcfba3a33/2b8908b98402e251#2b8908b98402e251
[5] http://www.imc.org/atom-syntax/mail-archive/msg17431.html
[6] http://bblfish.net/work/atom-owl/2005-10-23/example-1-v3.n3
Reply all
Reply to author
Forward
0 new messages