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

From: Henry Story <[email-masked]>
Date: Tue, 11 Jan 2005 10:41:53 +0100

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
>

---

From: Henry Story <[email-masked]>
Date: Tue, 11 Jan 2005 14:41:54 +0100

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.

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
>> <tag:example.com:2005_01_03>, called _e had two publication dates. 
>> Yet an
>> 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)
>>>
>> This is exactly right, except that id should absolutely not be 
>> inverse functional.