[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "Role of RSS in Science Publishing": Atom is in RDF format

That is an issue I have thought long and hard about, starting with
some writings 8 months ago on BlogEd mailing list [1]. I started
off thinking of it as an inverse functional property. But that then
makes it very difficult to distinguish the different
versions of an Entry as shown in [1]. I then made the same mistake
when modeling this in OWL [2] because I did not see the implications
of confusing the id with the Entry. I then tried adding
an EntryVersion object [3] to undo the harm.

In the end I just realized that "id" is best seen as simply a functional
property. It just requires one to make a little shift in your thinking.
Think of the id as your constant Entry over time that just points via the
1/id relationship to all the Entry Versions out there (which the common
mortals thing of as Entries). It makes sense when one gets used to it
and is very powerful :-)

Henry Story

[1] This mail from May 2004 nicely describes the problem
[2] for some reason I forgot the lesson of [1] when modelling [2]
[3] I then realised my mistake and tried to work with EntryVersion object
[4] And finally I realized that there was no need for such a thing
if id is not inverse functional.

Attachment: Atom.owl
Description: Binary data

On 11 Jan 2005, at 13:18, Ian Davis wrote:


I don't think this is correct. id _should_ be an IFP - it's the unique identifier for the element after all. I think you should relax any constraint on published having cardinality of 1. The same entry can be published multiple times.


On 11/01/2005 09:41, Henry Story wrote:
Just found this mail and thought it worth replying to. It points out a little bug
with the Ontology I just released lately. I made the entry id inverse functional.
That won't do.
If id is inverse functional, then given two entries with the same id
_f1----a-----> <Feed>
|---entry--> _e1 ---a-----> <Entry>
| |-----id----> <tag:example.com:2005_01_03>
| |---title---> "first verzion of the entry"
| |-published-> "20 Dec 2004"
_f1----a-----> <Feed>
|---entry--> _e2 ---a-----> <Entry>
| |-----id----> <tag:example.com:2005_01_03>
| |---title---> "second version of the entry"
| |-published-> "10 Jan 2005"
One would have to conclude that the anonymous nodes _e1 and _e2 were the same.
<tag:example.com:2005_01_03> -----1/id-------> _e
the inverse of id (called 1/id) can only have one value.
But if we tried to do this we would have to conclude that the entry with
<tag:example.com:2005_01_03>, called _e had two publication dates. Yet an
Entry can only have at most one.
So we end up with a contradiction by making id inverse functional.
By simply making it functional we bypass that problem, and we have correctly
model what we had: namely we have two Entries with the same id, which one can
think of as two versions of the same entry.
On 20 Dec 2004, at 18:45, Danny Ayers wrote:
Some of the possible approaches for an RDF/XML expression of the info
include (ignoring namespace decls & case!):

RSS 1.0 style:

   <entry rdf:about="vemmi://example.org/2003/32397">
this would be equivalent to making id inverse functional. If you do this
then you have the merging problem explained above.


A bit more plain-XMLy :

   <entry rdf:about="vemmi://example.org/2003/32397">
yes this just groups the entries in an "entries" tag. I don't see that it
adds much. (I know you are just pointing out all the different ways one can
do this)



   <Entry rdf:about="vemmi://example.org/2003/32397">
note: the RDF people think that having properties named
hasXXX is quaint. Or so at least DanC told me on #irc quite a
few months ago.

Closer to Atom 0.3 :

<entry rdf:parseType="Resource">
This is exactly right, except that id should absolutely not be inverse functional.
Just functional will do :-)

The last is kind of interesting, having the id attached to a blank node. If id were spec'ed as an inverse functional property that might work nicely.

But as far as I can tell none fit too well with :

<id href="vemmi://example.org/2003/32397"/>