On 12 Nov 2005, at 10:26, Danny Ayers wrote:
[snipped a very good conversation]
(I've cc'ed the atom-owl list, this is certainly in scope over there).
I think Bill's right about the direction being the issue, and has
probably got the right answer with adding another property to the
entryURI, but there's a fair bit of devil in the detail.
There's a slight mismatch between Atom's id and resource
identification in the RDF sense (Henry, you've looked at this hardest
- please correct me if I'm wrong). Entries can appear with different
values but the same id, e.g.
[[
If multiple atom:entry elements with the same atom:id value appear in
an Atom Feed Document, they represent the same entry. Their atom:
updated timestamps SHOULD be different.
]] 4.1.1
So if atom:id is treated as the entry resource URI then in a literal
RDF interpretation of the Atom spec you either end up with information
loss, older versions of the entry ceasing to exist (which doesn't
really work with either Atom or the RDF model) or contradictions, e.g.
more than one content value for an entry when the properties of the
resources are lined up together.
yes. Very well explained. I'll just fill out the details again below,
for those who may be new to this [1]. If you take the example
<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>
you DON't want to model it as:
<urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a>
:title "Atom-Powered Robots Run Amok"^^xsd:string;
:updated "2003-12-13T18:30:02Z"^^xsd:date .
because if a feed contained a correction of the above entry say
<entry>
<title>Atom-Powered Robots Run Amok in France</title>
<link href="http://example.org/2003/12/13/atom03"/>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2005-12-13T18:30:02Z</updated>
<summary>Some updated text.</summary>
</entry>
then you would have
<urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a>
:title "Atom-Powered Robots Run Amok in France"^^xsd:string;
:updated "2005-12-13T18:30:02Z"^^xsd:date .
And so by smushing the graph you would end up with something that was
not
very useful such as
<urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a>
:title "Atom-Powered Robots Run Amok"^^xsd:string;
:title "Atom-Powered Robots Run Amok in France"^^xsd:string;
:updated "2003-12-13T18:30:02Z"^^xsd:date .
:updated "2005-12-13T18:30:02Z"^^xsd:date .
And you would no longer know which title belonged with which updated
time
stamp.
The way we got around this in Atom/OWL is to make the entry itself a
blank node, with atom:id being a property of it. The unique
identification of the entry node being provided by the combination of
the id, updated (and some other stuff - multiple language support is a
complication).
Yes. The correct way to model it is therefore
[] a :Entry;
: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" ].
ie, as Danny says, to apply the :title, :link, etc relations to a
blank node
of type :Entry. By defining :id as functional we allow different
blank node
:Entry s to have the same id, and so the contradiction we had before no
longer exists.
This is not so complicated really, it is just easy to be mislead by
the 'id' word
and think that it must be a strong identity relation, rather than a
weaker one.
(ie, to think that the relation is not just functional, but also
inverse functional
symmetric and transitive)
This seems to work pretty well for most purposes - an
application could either take the "forget older entry versions"
processing model, or accumulate all the versions.
yes.
But when it comes to
saying what the entry in about, I think you'd almost certainly expect
all *versions* of an entry to be about the same thing, so the subject
of the statement would be the id URI. This is easy enough in RDF (the
id is a resource), but it's not obvious how this migght be expressed
in Atom syntax.
For a long time I wanted to put properties on the id when I felt they
were necessary properties of the thing. The problem as James Gosling
reminded me [2] is that defining essential properties of things can
be quite tricky. And I suppose that many a document that started about
one thing ended up being about something quite different.
So I would tend initially towards conservatism, and not put any property
on the id. One could of course invent/discover such a property
say :idabout
that would have the following rule associated with it
{ ?id :idabout ?obj .
?entry :id ?id . } => { ?entry :about ?obj . }
So the relation exists. It is just that it is very powerful relation,
with
a lot of consequences that the user may not fully appreciate.
Furthermore
it is not possible to write this relation out in atom syntax easily
because
the id is an element content
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
and so there is no way to attach elements to it.
So in short I'd say "what Bill said", and then run away...
The link element sounds like a good way to me. You would then have
something like
[] a :Entry;
:title [ :value "IBM Atom Robots Run Amok";
:type "text/plain" ];
:link [ :href <http://example.org/2003/12/13/atom03>;
:rel iana:alternate ];
:link [ :href <http://ibm.com>;
:rel xxx:about ];
:category [ a :Category;
:term "technology";
:scheme <http://example.org/categories/> ];
:id <urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a>;
:updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
:summary [ :value "IBM's new atom powered robots ran amok in
France, after having gone through some french integration courses.
Question is: did they integrate too well?";
:type "text/plain" ].
By the way, here is a nice little trick that I put in the Atom-OWL. A
link is defined as subclass
of rdf:Statement with the extra property by asserting a link one also
asserts the statement that it is,
ie:
{ ?link :subject ?state;
:rel ?rel;
:href ?obj . } => { ?state ?rel ?obj . } .
So the above entry is equivalent to the following
[] a :Entry;
:title [ :value "IBM Atom Robots Run Amok";
:type "text/plain" ];
iana:alternate <http://example.org/2003/12/13/atom03>;
xxx:about <http://ibm.com>;
:category [ a :Category;
:term "technology";
:scheme <http://example.org/categories/> ];
:id <urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a>;
:updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
:summary [ :value "IBM's new atom powered robots ran amok in
France, after having gone through some french integration courses.
Question is: did they integrate too well?";
:type "text/plain" ].
Which I think is neat.
Henry
Cheers,
Danny.
[1] I was already working on this problem in early 2004
https://bloged.dev.java.net/servlets/ReadMsg?list=users&msgNo=208
[2] https://bloged.dev.java.net/servlets/ReadMsg?list=users&msgNo=357
but in fact, a lot more is understood about essential properties
than
the problem of the ship of theseus would let one believe. A
lively topic
in philosophy.
--
http://dannyayers.com
