[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
<https://bloged.dev.java.net/servlets/ReadMsg?list=users&msgNo=208>
[2] for some reason I forgot the lesson of [1] when modelling [2]
<http://bblfish.net/work/atom-owl/2004-06-22/blogexample.html>
[3] I then realised my mistake and tried to work with EntryVersion object
<http://bblfish.net/work/atom-owl/2004-08-12/blogexample.html>
[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:



Henry,


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.

Ian




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.
Ie
<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:

<rdf:RDF>
   <head/>
   ...
   <entry rdf:about="vemmi://example.org/2003/32397">
      <title>Stuff</title>
      ...
   </entry>
...
</rdf:RDF>
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 :

<feed>
<head/>
...
<entries>
   <entry rdf:about="vemmi://example.org/2003/32397">
      <title>Stuff</title>
   ...
   </entry>
...
</entries>
...
</feed>
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)

----------------------------


Lumpier:

<feed>
...
<hasEntry>
   <Entry rdf:about="vemmi://example.org/2003/32397">
      <title>Stuff</title>
   </Entry>
</hasEntry>
...
</feed>
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 :

<feed>
...
<entry rdf:parseType="Resource">
   <id>vemmi://example.org/2003/32397</id>
   <title>Stuff</title>
...
</entry>
...
</feed>
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"/>

Cheers,
Danny.

--

http://dannyayers.com