Subject: AtomOWL & AtomIsRDF

From: Henry Story <[email-masked]>
Date: Mon, 17 Jan 2005 16:12:57 +0100

I have put up two pages (Paces) on the wiki.

One AtomOWL [1] just is a place to work on the latest RDF model of 
Atom, and fulfill
the requirement that Atom have a model.

The Other AtomIsRDF [2] is a place to track the way for Atom to fulfill 
its extensibility requirements, by closing the gap with RDF. As you 
will see there
is not a lot of difference really. So this should harm no one, but make 
it much easier to extend atom in a failsafe way.

Henry Story

[1] http://www.intertwingly.net/wiki/pie/AtomOWL
[2] http://www.intertwingly.net/wiki/pie/AtomIsRDF

---

From: Dan Brickley <[email-masked]>
Date: Mon, 17 Jan 2005 12:16:36 -0500

* Henry Story <[email-masked]> [2005-01-17 16:12+0100]
> it much easier to extend atom in a failsafe way.
 
I fear [2] is unfortunately named. Atom is RDF-like in some ways, 
but until the Atom spec says "Atom is RDF", Atom isn't RDF. A surface 
similarity to RDF's XML encoding, or even to RDF's graph data model,
isn't by itself enough to declare that Atom "is" RDF. For example, there 
have been threads here about defaulting, about data being implied if
missing, and other things that have no clear RDF equivalent. The name 
"Atom is RDF" goes somewhat against the decision record of this group,
which has been pretty clear in its non-RDFness. Wiki style tends towards 
the consensual, so I suggest renaming it to AtomRDF or similar.

Even as an RDF enthusiast, I find the name problematic. So I'm concerned
that "Atom is RDF" will annoy people needlessly, which would be a shame 
since the work you've been doing on an RDF/OWL view of the Atom format 
is both interesting and valuable.

Dan

---

From: Henry Story <[email-masked]>
Date: Mon, 17 Jan 2005 18:38:08 +0100

On 17 Jan 2005, at 18:16, Dan Brickley wrote:
> [snip]

Yes, very good point. I have created a new Page called AtomRDF [3], 
whose aim
is to track what would be needed for an Atom document to be an RDF 
document.
It is only if we are clear about these that it will be possible to come 
to
a reasoned decision on the value of perhaps bridging the gap. The gap 
is I
think a lot smaller than most people think (which is what I was trying 
to
emphasize with the AtomIsRDF name) But you are right, there still
is one.

>> [2] http://www.intertwingly.net/wiki/pie/AtomIsRDF
[3] http://www.intertwingly.net/wiki/pie/AtomIsRDF

---

From: Walter Underwood <[email-masked]>
Date: Mon, 17 Jan 2005 10:52:36 -0800

--On Monday, January 17, 2005 12:16:36 PM -0500 Dan Brickley <[email-masked]> wrote:
> but until the Atom spec says "Atom is RDF", Atom isn't RDF.

Call it "AtomAsRDF".

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Sam Ruby <[email-masked]>
Date: Mon, 17 Jan 2005 14:38:17 -0500

> is to track what would be needed for an Atom document to be an RDF 

I have a number of problems with the AtomRDF document as it stands now.

For starters, the current atom:generator element has optional "uri" and 
"version" elements, not "atom:uri" and "atom:version" elements. 
Unfortunately, these are quite different.

More siginificantly, the document does not address the largest issue, 
which is content.

I do believe that it would be possible, and perhaps quite useful, to 
define an XSLT tranform from Atom/XML to RDF/XML.

- Sam Ruby

---

From: Danny Ayers <[email-masked]>
Date: Mon, 17 Jan 2005 21:15:32 +0100

> Unfortunately, these are quite different.

Yurk, nice catch. I wonder if it might make sense (over on the RDF
side of the transform/fence) to notionally define namespace-qualified
terms as equivalent to the no-namespace ones in Atom syntax - that
shouldn't impact anything on the Atom side, should it?

> More siginificantly, the document does not address the largest issue,

Anything in particular in mind?

I think there may be a very clean mapping of the content by simply
taking the typing as used in Atom, defining each through XML Schema,
then using URIs for each as the value for rdf:datatype in literals. It
sounds complicated but in effect it should mean something like e.g.
type="XHTML" being replaced by
rdf:datatype="http://purl.org/atom/datatypes#XHTML", the rest of the
RDF/XML syntax being near-identical to Atom. Whether this is actually
possible is another matter...depends on the XML Schema datatype
business, and whether it's consistent with the best practices draft in
[1] (XML Schema Datatypes in RDF and OWL) - I've not had chance to
read yet..

The alternative would seem to be to add the type as simply another
literal-valued property of the content. Easy-peasy in principal and
practice, but less elegant and a step removed from Henry's AtomAsRDF.

> define an XSLT tranform from Atom/XML to RDF/XML.

Yep. Has anyone got one more recent than 0.3?

Cheers,
Danny.

[1] http://www.w3.org/2001/sw/BestPractices/XSCH/xsch-sw-20041216/

-- 

http://dannyayers.com

---

From: Henry Story <[email-masked]>
Date: Mon, 17 Jan 2005 21:51:02 +0100

> Call it "AtomAsRDF".

That is indeed a much better name. Ok, off to change the page again...

On 17 Jan 2005, at 20:38, Sam Ruby wrote:
> For starters, the current atom:generator element has optional "uri" 
> and "version" elements, not "atom:uri" and "atom:version" elements. 

Oh God! I just looked this up in "Xml in a Nutshell". I had not 
realized that
default namespaces did not apply to attributes. How awful! Is there any 
good reason
for this? Any clever way to fix it? Otherwise why is XML broken like 
this?

If there is no simple fix, I'll have to point this one out on the 
AtomRDF page
as something to find a solution to.

> More siginificantly, the document does not address the largest issue, 

Can you expand a little on this. I have put this wiki up in order to 
serve as a
reference point for all these problems. This is one I had not yet 
noticed, or not
under your description at least.

> define an XSLT tranform from Atom/XML to RDF/XML.

Yes. The problem is that one can xslt transform something to many many 
different
types of rdf/xml documents.

Also the purpose of narrowing the gap between Atom and RDF down to 0 is 
that it would help give a very clear foundation for explaining 
extensibility, when combined with the AtomOWL ontology. The power of 
this is very similar to the power one gains
with OO programming in creating frameworks.  The relationship between 
OO programming
and ontologies should be obvious from definition of ontology itself.

   "An explicit formal specification of how to represent the objects,
    concepts and other entities that are assumed to exist in some area of
    interest and the relationships that hold among them." [1]

So yes. If we can narrow the gap, we can do Object Oriented XML 
development: which
is way cool. (No fear, OO xml looks like plain old xml btw)

One solution may be to have what we could call a canonical Atom format 
that
would present an Atom document in a clean RDF way. This format would 
perhaps require
that all attributes be in the atom namespace.

Henry Story

[1] http://dictionary.reference.com/search?q=ontology
     from the online dictionary of computing.

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 17 Jan 2005 21:43:02 +0000

> Yep. Has anyone got one more recent than 0.3?

I'm waiting for the format to stabilize for publishing any mappings; my 
guess is that there are some Atom data structures that could see a lot 
of churn (links, dates, recursion) unless the consensus becomes 'enough 
already'.

Incidently the name AtomIsRDF isn't as problematic as the latent 
assumption - that Atom is some of kind of degenerate or special case of 
RDF. My opinion is that's a losing strategy if the goal is wider 
adoption of RDF.

cheers
Bill

---

From: Henry Story <[email-masked]>
Date: Mon, 17 Jan 2005 22:41:28 +0100

yes, and of course since OWL can specify mappings between the rdf 
vocabulary
and the atom vocabulary it may even be possible to specify that 
atom:type is a
sub property of rdf:datatype so that we end up with:

atom:type="&atom;XHTML"

Any further simplification ideas would be welcomed. The aim is to make 
the
rdf as invisible as possible to anyone other than atom extension 
writers. If we
have to bring out difficult rdf tools, so be it.

Henry Story

On 17 Jan 2005, at 21:15, Danny Ayers wrote:

> RDF/XML syntax being near-identical to Atom.

---

From: David Powell <[email-masked]>
Date: Mon, 17 Jan 2005 21:56:50 +0000

> Bill

I put together a quick hack the other day as an experiment to see if
it was possible: http://djpowell.net/tmp/atom2rdf.xsl

It supports -04 with PaceExtensionConstruct (treating all Structured
Extensions as unknown, but preserving them for round-tripping).

It doesn't handle xml:base or xml:lang yet. I'll put it on the Wiki
when I've sorted it out, but here it is as a preview.

-- 
Dave

---

From: Henry Story <[email-masked]>
Date: Mon, 17 Jan 2005 23:38:50 +0100

The goal is not at all the wider adoption of RDF. The way I am 
proposing atom
be seen as RDF will hopefully be completely invisible to anyone who 
does not
know that it is.

The point of being able to - if you will allow me the C,C++ idiom - 
cast an atom document to RDF will be to make it clear how to structure 
extensions. RDF alone does
not do this, but RDF and the AtomOWL ontology does. It does this in a 
way that
all Object Oriented programming languages do this: by specifying how 
concepts hook
together.

Take for example the following extension proposed recently

    <entry>
       <id>tag://sometag</id>
       <geo:x>10.1</geo:x>
       <geo:y>57.3</geo:y>
       ...
     </entry>

this implies the following rdf graph

_e -entry-> _E
            |-id--><tag://sometag>
            |-geo:x->"10.1"
            |-geo:y->"57.3"

which presumably would mean that _E had to be both
an Entry and a geographical location, which is a very
unintuitive concept, and very likely *not* what the
extension author intended. It would for example meant
that this object would be a different object if it had
a different id.

What he probably intended was either

- That the author was at some particular location, in which case he 
should
  probably have added attributes to the author object, through some foaf
  ontology predicate.

- Or that some event the Entry is about was at some particular 
location. In which
case this should have gone into the <content> </content> space by using 
an event
ontology. Eg:

   _e --content-> _event --is-a-><xyz:Event>
                  |---location--->_loc --is-a-><geo:location>
                                  |--geo:x-->"10.1"
                                  |--geo:y-->"57.3"

The Object of the content predicate can accept anything (in java this 
would
be a method that returned an Object), so it can accept among other 
things an
xxx:Event.

If you look at the AtomOWL spec, you will see that among other things it
is simply a specification of what types of objects a relation can take
as subject and as Object.

Now we could define other mappings from xml to RDF. I have put forward 
some
proposals that I think could bring this much closer to the intuitions 
of Tim Bray
as expressed on this list. But we just don't have time. And since Atom 
is anyways
so close to being RDF, I think the easiest route is simply to use the 
work done by others. I think the price is pretty minimal. And we will 
end up with a format
that is extensible and even better defined than RSS1.0

Henry Story

On 17 Jan 2005, at 22:43, Bill de hÓra wrote:
> assumption - that Atom is some of kind of degenerate or special case 
> of RDF. My opinion is that's a losing strategy if the goal is wider 
> adoption of RDF.

---

From: Danny Ayers <[email-masked]>
Date: Tue, 18 Jan 2005 01:26:09 +0100

On Mon, 17 Jan 2005 23:38:50 +0100, Henry Story <[email-masked]> wrote:

> an Entry and a geographical location, 

...or an entry *with* a geographic location (or something completely different).

which is a very
> ontology. 

Maybe, but there's always the trade-off between accuracy of modelling
and difficulty of handling the stuff. There's really nothing to stop
the resource identified in <id> being a geological event with a
geographic location as well as something with a representation in the
content of an entry in an Atom feed. The indirection can be reduced
with the data expressing what the entry is, rather than what it is
about. This example probably works better than most in human terms, as
the entry could be an entry in an event log, though you could end up
with the author of the feed entry being the creator of the
earthquake...

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 18 Jan 2005 01:18:13 +0000

> this implies the following rdf graph

[On a technical point, I would disagree the graph is implied. As I said 
earlier, this kind of assumption concerns me.]

> as subject and as Object.

This is what I'm getting from the proposal - if range and domain for 
extensions are determined, a semantically 'consistent' (I won't say 
'meaningful') extensibility framework for applying them to Atom 
structures can be established. So since we have evaluation rules above 
the level of data structures, we can determine if any extra metadata 
satisfies the constraints.

Two things come to mind if that is a fair summary.

First, I don't see how it can be done generally without RDF backed 
ontological modeling to begin with - which would be AtomIsRDF. Correct 
me if I'm wrong, but I think for this to work I would need to know what 
the essence of Atom domain constructs are before I can determine whether 
a new property can be correctly be applied to one.

Second, I've said before, my position is that Atom doesn't require 
extensibility. Tim for one, has taken umbrage with my use of the word 
'extensible', but what you're proposing isn't far away from what I would 
mean by it - extensions and their relationships are processed through an 
evaluator. I just happen to think we don't need to spec this yet*.

So, I'm not -1 on this, but I do think it's out of scope.

cheers
Bill

* I would include trying to make explicit whatever the child_of() 
evaluation rules might be for XML containership here.

---

From: Henry Story <[email-masked]>
Date: Tue, 18 Jan 2005 09:02:16 +0100

On 18 Jan 2005, at 02:18, Bill de hÓra wrote:
> [On a technical point, I would disagree the graph is implied. As I 
> said earlier, this kind of assumption concerns me.]

It will be when the gap between atom as it currently is and where it
would have to be for it to be correctly seen as RDF is closed. As you 
see
there is not that much to closing the gap. And there are many ways of 
doing this,
which need to be looked at, and evaluated for those that form the best
compromise solution.

> me if I'm wrong, but I think for this to work I would need to know 
> what the essence of Atom domain constructs are before I can determine 
> whether a new property can be correctly be applied to one.

Yes, if I have understood you correctly. That is why I have AtomOWL 
which gives you
the essence of the Atom domain constructs. For example it specifies that
atom:id is functional, which says that two Entries are different if 
they have
different ids. I have tried to express all the number constraints that 
the spec
defines too, such as a Feed requiring one Header and no more.

I call this AtomAsRDF rather than AtomIsRDF because the point is that 
we are trying
to make this completely invisible for anyone who does not want to know, 
or has not
yet had time to learn these constructs.

> 'extensible', but what you're proposing isn't far away from what I 
> would mean by it - extensions and their relationships are processed 
> through an evaluator. I just happen to think we don't need to spec 
> this yet*.

I think that the spec does speak about extensibility and a model for 
atom.
With AtomAsRDF and AtomOWL I provide both. Even if we did not need this 
yet,
it certainly won't harm to track the differences, and the obvious 
problems
that some decisions entail.

For example modeling the Person construct it is obvious that
the e-mail address should be "inverse functional" and not functional as 
we have it
now. Ie if we have 2 Person objects (be they in an author or 
contributor tag)
anywhere in the xml with the same email address, we should be able to 
conclude
that these are in fact the same person. The model  sometimes also can 
help spot
gaps in the spec, which cannot be a bad thing. It is better these gaps 
be found now
than later when it will be difficult to change anything.

> So, I'm not -1 on this, but I do think it's out of scope.

Ok. I take that as being that your kind of for it :-)

By the way I think that there are many people out there who don't want 
to hear
about RDF in so far as it is plastered all over their xml in big bold
letters. They don't want rdf:li here and rdf:resource there. They don't 
want xml
that is not in a nice tree shape, but just a set of statements about the
relationship between things. They want to use XPath and other well
tested tools. Apart from that they probably don't have anything really 
against
RDF (apart from that one has the suspicion it could have been better 
done, but
then that is true with all technologies - one need look no further than 
default
namespaces in xml). So I think these people have nothing to worry about 
the
current proposal. They have everything they want. And they have 
something extra:
in their spare time they can learn about that weird thing called rdf. 
This
would be seamless integration. And I think is the foundation of a good 
long
lasting compromise.

---

From: Henry Story <[email-masked]>
Date: Tue, 18 Jan 2005 09:06:16 +0100

> ...or an entry *with* a geographic location (or something completely 

Yes. It all depends of course on how the geo ontology has defined its
predicates. My point was to show a little how this gives a framework for
extension writers to think about their extensions. It constrains 
extension
writers the way logic constrains us in what we say, and that has never 
stopped
people from speaking gibberish.

It would probably help to work with a concrete example. That would show 
what
effect each decision had, and give us a good way to discuss whether 
that was
what the author intended. Perhaps we could start a thread taking a 
reasonable
extension idea, and use that to discuss how they would be best off 
writing  their extension in Atom+OWL.

Henry

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 18 Jan 2005 09:23:02 +0000

> Ok. I take that as being that your kind of for it :-)

More than that; I think an ability to a) evaluate extensions in a 
uniform manner, b) determine if they are being applied appropriately, c) 
have the evaluation results output as more metadata, is immensely 
valuable. I think when you appreciate that value, the point of 
technologies like RDF become more apparent. But in my mind this work 
falls into innovation space rather than standards space.

cheers
Bill

---

From: Norman Walsh <[email-masked]>
Date: Tue, 18 Jan 2005 16:22:56 -0800

Just a note for this thread. I plan, eventually, to add the OWL mappings
to my RELAX NG schema for Atom and, perhaps, to build a stylesheet that
produces a stylesheet that does the conversion from those annotations.
But I won't get started, I expect, until there's broader consensus on
what the mapping should be.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Never contend with a man who has
http://nwalsh.com/            | nothing to lose.-- Gracián

---

From: Norman Walsh <[email-masked]>
Date: Wed, 19 Jan 2005 18:54:39 -0800

/ Danny Ayers <[email-masked]> was heard to say:
| I'd be interested to hear what you reckon to the mapping, in
| particular the content stuff, I mentioned earlier in the thread-

I'm sorry Danny, my attention has been mostly focussed elsewhere and I
haven't really followed this thread. I want there to be a standard
mapping, but I'm not too worried about what it is exactly.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Simplicity is always a virtue.--Edward
http://nwalsh.com/            | Abbey