Post

Author

Password

URI Delete Entry?

Title

Content

<div>Ian Davis asked the 
<a href="http://internetalchemy.org/2005/12/transliteration-or-interpretation">question</a>:
<blockquote>
 When creating RDF schemas based on existing data formats you
 soon hit the inevitable decision point - should you simply
 produce an RDF description of the syntactic format or interpret
 it and produce a semantic model of the format?
</blockquote>
This was one of the puzzles with trying to express the Atom
Syndication Format (
<a href="http://www.ietf.org/rfc/rfc4287">RFC 4287</a>) in RDF. 
(Ooh, that felt good - let me do that again: 
<a href="http://www.ietf.org/rfc/rfc4287">RFC 4287</a>). A lot
of time went into trying different versions (work from 
<a href="http://djpowell.net">David Powell</a>, 
<a href="http://blogs.sun.com/roller/page/bblfish">Henry Story</a>,

<a href="http://gmuer.ch/me">Reto
Bachmann-GmÃÂ¼r</a> amongst others). The
latest version (
<a href="http://dannyayers.com/svn/pragmatron/atom-owl/AtomOwl.n3">this</a>,
I think) could maybe be described as being a hybrid. It has
characteristics of a transliteration, so an 
<a href="http://atomowl.org">AtomOWL</a> instance graph could be
viewed as describing a specific Atom format document, or
alternately as an interpretation describing the entities and
relationships that are defined in the Atom spec. It's a compromise
which should reasonably fulfil several informal constraints:
<ol>
 <li>must be true to the Atom spec</li>
 <li>must be 
 usable in RDF/OWL systems</li>
 <li>should be usable in a "degenerate" form</li>
</ol>
(The first point is really where the transliteration comes
from).
 Now you'd think being true to the Atom spec would be pretty
straightforward. The RFC 4287 had the influence of people who
*know* related document specifications and are strong on web
architecture. However usefully describing all this in a model like
RDF/OWL is far from trivial. Web services, dude. Issues such as the
relationship between a resource and its representations when
considered in the light of change over time in an multi-lingual
environment where multiple encodings are possibles…anyway
that spawned a whole fresh bunch of work that Reto was looking at (
<a href="http://dannyayers.com/svn/pragmatron/atom-owl/info-atom.n3">schema</a>,
probably not the latest).
Being usable in RDF/OWL systems isn't anything like so broad a
problem, however as it stands the schema's OWL Full and includes
rules (neither of which I'm very comfortable with). But the subset
of the schema without these parts probably captures enough for most
purposes.
The specific 
degenerate form part referred to is that implemented in
many (most?) aggregator tools. One of the significant aspects of
Atom is it introduces a fairly clean form of versioning. A specific
entry may be updated over time. Most tools forget previous versions
of an entry, but the information can be captured in Atom. The
degenerate approach says this entry resource has this single piece
of content, but in reality there may be multiple version of a
single entry. (This is where a key part of the rules come in, to
express a 
<a href="http://esw.w3.org/topic/CIFP?highlight=%28cifp%29">Combined
Inverse Functional Property</a> (CIFP) consisting of 
<code>atom:id</code>, 
<code>atom:updated</code> and 
<code>atom:content</code>). The AtomOWL for this will probably
benefit from a good few more wash cycles, but seems to work
basically ok. 
[If anyone can show me how to do CIFPs without rules, I'll be
most grateful…]
So, what of transliteration and interpretation? The approach
taken here seems very close to that 
<a href="http://harry.hchen1.com/2005/12/20/201">described</a> by
Harry Chen :
<blockquote>
 I first map the syntactic format of the data into RDF, and
 then build external inference rules to produce a more expressive
 semantic model of the original data.
</blockquote>
Luckily the majority of the Atom semantic model can be mapped
fairly directly onto simple entities/relationships. The difficult
corners being the external models on which the Atom spec depends
(WebArch++) and the twisty semantics around entry identity. 
(Come to think of it, I argued with a few folks over Atom's
approach to id way back when. I thought at the time the use of a id
URI to point to the representations of different resources (the
content, link URI etc) was probably broken. I now reckon I was
wrong about broken, but that ids could probably have been done in a
little more straightforward fashion…)
One other point that might have relevance to the
transliteration/interpretation choice is whether it will be
necessary to produce data in the original format from RDF
instantiations (maybe round-trip). I would guess a transliterated
schema would be considerably easier, but whether that would be
worth the cost of a suboptimal representation is another matter.
I'm optimistic that roundtripping with AtomOWL will be possible,
though Henry and/or Reto had doubts (I forget on which specific
point(s)).[Danny]
</div>