Subject: Atom extensibility

From: Henry Story <[email-masked]>
Date: Fri, 7 Jan 2005 15:54:18 +0100

Thanks for the encouragement.

But I think this is not just something that can happen completely 
independently. Extensibility is part of the Atom Charter, so this is in 
fact important to Atom in a much more central way.

The question is exactly how should the interesting discovery that an 
Atom document is an RDF document [Ø] be used to fulfill the charter 
requirements on extensibility?
Clearly it could completely underpin the extensibility framework, and 
so allow the Atom charter to be successfully fulfilled.

I am in agreement with Danny's recent post [1] that something has to go 
in the charter that guides this relationship.

I have some ideas on how this could be done, but I would rather just 
ask the question in this post, and not confuse the issue with 
potentially misguided solutions to the problem.

So perhaps we can open this thread as a place to post ideas on the 
topic.

Henry Story

[Ø] though it still remains to be formally proven
[1] A similar question was just asked by Danny Ayers
http://www.imc.org/atom-syntax/mail-archive/msg11918.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg11909.html

On 6 Jan 2005, at 19:27, Paul Hoffman  wrote [2]:
> At 6:43 PM +0100 1/6/05, Henry Story wrote:
>> To restate my point in your terms I believe I have shown that your 
>> point (4) is currently true. Ie (4) is not a future. It is currently 
>> and actually true.
>>
>> Like RSS1.0 Atom is a constrained form of RDF. But unlike RSS1.0 it 
>> is very inconspicuously so. IE. Anyone just looking at atom would 
>> never guess that it is RDF.
>>
>> I have tried to show this in an e-mail [1] to this list. Of course it 
>> would require more work to show this definitively to be the case. I 
>> have not gone through the details of this work because I'd like to 
>> have the backing of the group to do this officially, before I spend 
>> too much time on it. Also I would probably find a  lot of people a 
>> lot more knowledgeable than me to help on this task if there was a 
>> declared interest.
>
> Wearing my co-chair hat, the reason I didn't give backing is that I 
> didn't hear much desire for it. That is not to say you shouldn't do 
> it, just that it was not needed to be a WG work item.
>
> It is quite common in the IETF that there are set of WG work items 
> *and* individually-submitted drafts that extend, explain, or otherwise 
> refer to the WG work items. If you wanted to create a draft that would 
> eventually become an Informational RFC that explained how the Atom 
> format as we are discussing it relates to RDF, I'm sure that would be 
> useful to some people (and possibly many more than we can imagine 
> right now).
>
> So, instead of me saying "feel free to do it", let me encourage you to 
> do it. It doesn't affect the WG products or timelines, but could have 
> a positive effect of eventual Atom use.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>

---

From: Tim Bray <[email-masked]>
Date: Fri, 07 Jan 2005 07:48:25 -0800

> so allow the Atom charter to be successfully fulfilled.

I think that the charter requirements on extensibility will be filled 
adequately with PaceExtendingAtom.  I think they would be filled still 
better by adopting PaceMustUnderstandElement, but apparently others are 
unconvinced.  Extensibility via a mapping to RDF seems to me to add a 
lot of complexity (most people have never bothered to learn graph 
theory) without any real benefit. -Tim

---

From: Danny Ayers <[email-masked]>
Date: Fri, 7 Jan 2005 19:45:43 +0100

On Fri, 07 Jan 2005 07:48:25 -0800, Tim Bray <[email-masked]> wrote:
> unconvinced.  

The charter requirements could be fulfilled in any number of ways, not
all of them useful.

I think PaceMustUnderstandElement may well be a good idea.
PaceExtendingAtom does shield Atom core data from unwanted
interference from foreign elements, but that shielding can still
happen alongside partial understanding.

Extensibility via a mapping to RDF seems to me to add a
> theory) without any real benefit. -Tim

There are feeds in RDF from the blogs of millions of users that
haven't learnt graph theory.
Given Henry's proposal, the person that uses RSS 2.0 today would
notice no additional complexity. The only people that would need to
know a little about RDF would be those that wish to develop
extensions. All they would really need to know are a few syntax rules.

On the other hand, if extension markup can appear anywhere (as in
PaceExtendingAtom) application developers will have to deal with the
complexity of handling every extension completely on a completely
case-by-case basis.

Extensibility via a mapping to RDF will happen, whether it appears in
the specifications or not. Whether it can be done consistently across
extensions will depend on how consistently those extensions are
expressed in Atom.

I personally would prefer an RDF-oriented approach in the core, as I
think RSS 1.0 demonstrates its utility. But if there is obtuse
antagonism towards RDF then a reasonable compromise would seem to be
some having some simple structural syntax constraints that extensions
should follow.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 7 Jan 2005 11:17:07 -0800

At 7:48 AM -0800 1/7/05, Tim Bray wrote:
>I think that the charter requirements on extensibility will be 
>filled adequately with PaceExtendingAtom.  I think they would be 
>filled still better by adopting PaceMustUnderstandElement, but 
>apparently others are unconvinced.  Extensibility via a mapping to 
>RDF seems to me to add a lot of complexity (most people have never 
>bothered to learn graph theory) without any real benefit. -Tim

Wearing my co-chair hat, I fully agree with Tim. We are already 
fulfilling our charter requirements without defining a mapping to RDF.

A document that shows another way to do extensibility through RDF is 
fine, but it is not required by the charter (nor by the vast majority 
of active posters on the list).

--Paul Hoffman, Director

---

From: Lance Lavandowska <[email-masked]>
Date: Fri, 7 Jan 2005 13:29:54 -0600

> extensions. All they would really need to know are a few syntax rules.

As a nobody who still cannot quite grasp RDF, I really like Henry's
proposal.  Danny can have his RDF cake, and I can eat it too.

Lance

---

From: Danny Ayers <[email-masked]>
Date: Fri, 7 Jan 2005 21:38:13 +0100

> proposal.  Danny can have his RDF cake, and I can eat it too.

Mmmm...cake....

http://semtext.org/2004-02/slides/img4.html

---

From: Robert Sayre <[email-masked]>
Date: Fri, 07 Jan 2005 15:56:52 -0500

> requirements on extensibility? 

Have you figured out a way to deal with this:
<link rel="via" href="..." title="..." length="..." />

>
>
> So perhaps we can open this thread as a place to post ideas on the topic.

I think the debate is pretty much settled for client GUI software. RDF 
doesn't help a bit. A more interesting situation is a server receiving 
Atom entries to publish. For the purposes of discussion, let's say the 
server trusts the client.

It gets a POST with a fairly average atom entry, but there are 
extensions in funny places. Like most people, the server stores standard 
fields in a relational database, so there are columns for title, 
summary, etc. in a table called something like "journal_entries". It 
would be fairly easy to store immediate children of entry in an 
"unknown_xml" field, and pass them through, but what about the other 
extensions? Using an RDF store might make this problem a lot easier, but 
I don't forsee a mass migration in that direction happening this year or 
next.

POST ...

<entry xmlns="..." xmlns:funky="..." xmlns:rdf="...">
<title>My cat</title>
<author>
 <name>me</name>
 <funky:thing>adfadf</funky:thing>
</author>
<summary>I took my cat on vacation</summary>
<content ... funky:att="foo">It was really fun</content>
<funky:thing>adfadsfa</funky:thing>
<rdf:RDF>
 ...
</rdf:RDF>
</entry>

So, what's the algorithm and storage strategy that will allow maximum 
extensibility but not require servers to re-architect?

Robert Sayre

---

From: Danny Ayers <[email-masked]>
Date: Fri, 7 Jan 2005 22:00:41 +0100

> theory) without any real benefit. -Tim

btw, here's quite a good RDF tutorial which doesn't involve graph theory:

http://www.xml.com/pub/a/2001/01/24/rdf.html

-- 

http://dannyayers.com

---

From: Lance Lavandowska <[email-masked]>
Date: Fri, 7 Jan 2005 15:28:48 -0600

The latter.

> http://www.imc.org/atom-syntax/mail-archive/msg11850.html is clearer.

On Fri, 07 Jan 2005 12:27:48 -0800, Tim Bray <[email-masked]> wrote:
> On Jan 7, 2005, at 11:29 AM, Lance Lavandowska wrote:
> 
> Oops, Henry says
> http://www.imc.org/atom-syntax/mail-archive/msg11850.html is clearer.
> Is that what you mean? -Tim
> 
>

---

From: Sam Ruby <[email-masked]>
Date: Fri, 07 Jan 2005 17:14:32 -0500

I'm not sure why this discussion has popped up again, but it seems to me 
that there will always be people who only can grasp the bits and bytes 
that actually go across the wire, and there will be several sets of 
people who can only grasp the higher level abstractions that they see 
through the lens of their favorite schema aware tool.

For quite a while, the compromise seems to have been that the format 
itself will be defined in terms of what goes over the wire, and that any 
number of non-normative mappings could be included in the specification. 
  (Non-normative only in the sense that should there ever prove to be an 
inconsistency, the language in the format specification should prevail).

In the case of RDF, there exists a standard means to associate a 
document with a mapping.  This standard is called GRDDL. [1]

It defines two mechanisms for associating a document with a stylesheet. 
  A special case (useful for XHTML) is to define a link with a rel of 
"transformation" to associate this document with an XSL stylesheet.  It 
would seem to me that such an approach would work well with Atom too.

A more general mechanism is to define a grddl:interpreter attribute on 
the root element.  Such an approach would work well too.

The way I see this working in practice is that should anybody ever 
actually develop a tool that is capable of doing "partial understanding" 
in a meaningful and useful manner, there would be a rush on the part of 
tool developers to add this one element or attribute to any feeds that 
employ an extension.

Meanwhile, it would not be harmful to mention this one element or 
attribute (anybody have a preference) in the specification.

- Sam Ruby

[1] http://www.w3.org/TR/grddl/

---

From: David Powell <[email-masked]>
Date: Fri, 7 Jan 2005 22:38:24 +0000

I'd say that the most useful basic features of RDF are:

1) Property names are namespaced for extensibility.

2) Important entities can be assigned global identifiers so that they
   can be referred to externally.

3) Statements are properties of an object rather than being simple
   name/value pairs.
   
4) The model has properties such as monotonicity: which results in
   statements having a fixed meaning that is not negated by the presence
   of other statements; this makes it possible to mix vocabularies
   without needing lots of coordination to prevent them from conflicting.

We have 1), and 2) near enough already in Atom.

3) I think would be useful, even if it is just done by an implication
in the spec that "sub-elements of entry are properties of the entry",
etc.

4) is an important guideline for extension authors I think. If
extensions could affect the meaning of core elements or other
extensions, it could cause some pretty bad interoperability problems.

I think if we ensure that these properties apply to the Atom model,
then it will be beneficial to Atom, and will make any mapping between
Atom and RDF a lot simpler.

-- 
Dave

---

From: Robert Sayre <[email-masked]>
Date: Fri, 07 Jan 2005 18:07:45 -0500

Sam Ruby wrote:

> I'm not sure why this discussion has popped up again...

> attribute (anybody have a preference) in the specification.

GRDDL addresses the concerns of some participants, but I don't think it 
addresses the issues being raised by David Powell[0] and myself[1].
I think our question is this: where are extension elements part of the 
Atom model, and where do they constitute an extension of the Atom model?

The arbitrary extension that RDF allows is not what we need--there's a 
reason almost no one syndicates complex objects in dc:subject statements.

Robert Sayre

[0] http://www.imc.org/atom-syntax/mail-archive/msg11935.html
[1] http://www.imc.org/atom-syntax/mail-archive/msg11936.html

---

From: Tim Bray <[email-masked]>
Date: Fri, 07 Jan 2005 15:45:58 -0800

> Atom and RDF a lot simpler.

Please propose specific edits to current drafts for the WG's 
consideration. -Tim

---

From: Antone Roundy <[email-masked]>
Date: Fri, 7 Jan 2005 17:03:15 -0700

Let me see if I can correctly restate the following in language I'm 
familiar with--let me know whether I've got this right or not:

> 1) Property names are namespaced for extensibility.
Elements not defined in the Atom core must be namespace qualified (and 
in a different namespace than Atom, of course).

>    can be referred to externally.
An entry or feed can be referred to from arbitrary places, whether in 
or out of the feed where it lives, using the value found in its 
identity construct.

> 3) Statements are properties of an object rather than being simple
Child elements say something about their parents.  (This seems so 
intuitively obvious that I wouldn't think people would make XML that 
didn't work this way, but from the sound of it, there are examples out 
there of XML where child elements aren't related to their parents.  I 
for one would understand the importance of making this explicit if I 
could see such examples).

>    without needing lots of coordination to prevent them from 
No element can change the meaning of its siblings.

---

From: Eric Scheid <[email-masked]>
Date: Sat, 08 Jan 2005 15:33:46 +1100

On 8/1/05 11:03 AM, "Antone Roundy" <[email-masked]> wrote:

> (This seems so 

it's often not so much a case of breaking a parent-child relationship, but
asserting a sibling relationship ... even in atom, we already have
/feed/head/author which applies to /feed/entry.

What happens when some moblogger wants to put <geo:coords> into /feed/head
but have it apply to all /feed/entry except where there are specific
<geo:coord> for a given <entry>?

e.

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 08 Jan 2005 16:07:56 +0000

David Powell wrote:
> [...]

David,

I've stated my position elsewhere, but I wanted to qualify what you said 
there. Atom in my mind does not provide extensibility, it provides 
modularity. Sure, that's nitpicky, but I think it's a useful distinction 
to hold.

Whether modularity is sufficient for Atom's evolution as a format is a 
separate matter.

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 08 Jan 2005 16:03:45 +0000

> theory) without any real benefit. -Tim

I won't talk about 'complexity' here, but will talk about cost/benefit. 
My take on this is that extensibility via a mapping to RDF seems to me 
to add cost for implementors and those processing Atom. Writing Atom as 
RDF is cheap enough. Not enough people are processing RSS1.0 and other 
RDF formats *as* RDF; I speculate that indicates an issue on receipt of 
the data.

I'm +1 on not requiring an RDF mapping for Atom. Those of us that like 
to use RDF can figure out how to.

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 08 Jan 2005 16:15:05 +0000

> attribute (anybody have a preference) in the specification.

It's not clear to me that GRDDL is planned to become a recommendation. 
Does anyone know what the roadmap for GRDDL is?

Sam I'm tempted to use the 'put in the implementors guide' - calling 
GRDDL a standard is a reach imho.

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 08 Jan 2005 16:23:23 +0000

> Atom model, and where do they constitute an extension of the Atom model?

Robert,

My answer to this question is that Atom doesn't have a model in terms of 
being able to talk about extension so there's no point discussing it. 
Extensibility is probably out of scope for the format.

cheers
Bill

---

From: Tim Bray <[email-masked]>
Date: Sat, 08 Jan 2005 10:13:57 -0800

On Jan 8, 2005, at 8:23 AM, Bill de hÓra wrote:

> My answer to this question is that Atom doesn't have a model in terms 
> of being able to talk about extension so there's no point discussing 
> it. Extensibility is probably out of scope for the format.

I'm not going to let that go unchallenged.  The ability to put your own 
markup in a feed entry and be confident that it will not cause 
receiving software to break, and that it will be there for receiving 
software that actually knows how to deal with it, is what many people 
describe using the word "extensibility".  I think that Atom is, in a 
popular usage of the term (a large majority usage, I'd bet, but without 
backing statistics) extensible.

The people who insist that you have to have to buy into a 
graph-theoretical KR model to be able to use the word "extensible" live 
in a universe that is self-consistent, but it's not the one where I 
work. -Tim

---

From: "Jeremy Gray" <[email-masked]>
Date: Sat, 8 Jan 2005 11:44:25 -0800

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]] On Behalf Of Tim Bray
> Sent: Saturday, January 08, 2005 10:14 AM
> To: Bill de hÓra
> Cc: 'Atom WG'
> Subject: Re: Atom extensibility, RDF, and GRDDL

--snip--

> in a universe that is self-consistent, but it's not the one where I 

Having stepped back from both Atom and RDF a bit during the last few months,
in part because I want to make sure I'm not wearing X-coloured glasses too
often, but also because I find that I get too invested in and stressed out
by some of the more heated discussions :), I've been trying to avoid jumping
into this thread, but think its about time that I chime in and make my
feelings known on this subject.

It has long been apparent that the Atom community is not ready for RDF.
While much of the industry is finally starting to see the benefits of
semantic web technology, hence the emergence of terms like "semantic
integration" (as an evolutionary step beyond current data integration
techniques/tools/etc.), Atom and its community just aren't there yet.

RDF is unfortunately one of those things that is difficult to understand
until you've been bitten by one or more of the issues that it addresses and
find yourself in a position to "get it". Once you need it, you "get it".
Once you've "gotten it", you use it. Once you've "gotten it", it also
becomes frustrating to watch other people suffer while not "getting it".

You have the Atom community on one side, looking at RDF and thinking "the
syntax is dumb, the model is unnecessary, XML is enough." Then you have the
RDF pundits on the other side thinking "How can these guys not get it yet?"
And this isn't meant to slight the Atom community in the least. The Atom
community doesn't get it yet because it hasn't needed it yet, and
unfortunately, as I mentioned before, RDF is one of those things that is
hard to really "get" until you really need it [1].

And, as I've come to feel over the last few months, this can actually be
seen as a _good thing_:

Atom (or its successor) will adapt to (or simply somewhat align with) RDF
when its community "gets it", which will occur if and only if / when and
only when they _need_ it.

The problem is that in the meantime most of the arguments from the RDF
pundits are not only largely misunderstood or just seen as irrelevant, they
act _against_ the intentions of the RDF pundits by coming off as the
rantings of zealots of those want codified things that are obvious and who
live in some strange world where everything is a graph. Not that this is the
case, just that it ends up appearing as such. And I can safely say both of
these because I am one of those zealots. :)

With that in mind, here's what I would suggest:

Henry, keep posting your periodic messages trying to softly help people
understand RDF (and OWL, as many of your posts rely on it). Everyone seems
to have missed how your most recent posts showed that an OWL reasoner and
the rules provided to it would keep an application from even having to
_implement_ logic to decide what entries should be merged or kept separate,
and they all seemed to miss the fact that the included locations could be
deemed equivalent and then merge together any information and/or relations
ascribed to each of the two expressed locations. These are worthwhile things
for people to understand, so keep at it. At least one of us needs to keep
trying to help the community "get it", and in recent months I feel you have
been doing the best job delivering that message in a clear, even-handed
fashion.

In general, the RDF pundits need to step back and recognize that until such
time as the community has been bitten, needs, and subsequently "gets" the
semweb, the best thing you can do is recognize that an RDF version of Atom
will need to be created as a mapping, that mappings will also need to be
created for any Atom extensions, and to spend your time helping Atom (and
its extension authors) avoid doing things that will directly hamper RDF
mapping efforts. Get working on those mappings, keep them in sync, keep the
feedback loop going between the main effort and the mapping efforts, and
work to create apps that will help the community edge closer to "getting
it".

Jeremy

[1] This is worsened by the fact that the specification documents were
largely HORRIBLE for several years, and because the intentions behind and
syntax resulting from the RDF/XML effort is often misunderstood, but those
are subjects for another place and time. :D

---

From: "Jeremy Gray" <[email-masked]>
Date: Sat, 8 Jan 2005 11:48:02 -0800

> From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bill de hÓra
> Sent: Saturday, January 08, 2005 8:04 AM
> To: 'Atom WG'
> Subject: Re: Atom extensibility

--snip--

> to use RDF can figure out how to.

+1

Jeremy

---

From: "Jeremy Gray" <[email-masked]>
Date: Sat, 8 Jan 2005 11:48:48 -0800

> Sent: Saturday, January 08, 2005 8:15 AM
> To: 'Atom WG'

--snip--

> GRDDL a standard is a reach imho.

GRDDL is too from from being a standard to even merit mention (in the Atom
spec) as a mapping mechanism between Atom and RDF.

Jeremy

---

From: Danny Ayers <[email-masked]>
Date: Sat, 8 Jan 2005 22:20:54 +0100

> backing statistics) extensible.

FOLDOC [1] has:
[[
extensible
<programming> Said of a system (e.g., program, file format,
programming language, protocol, etc.) designed to easily allow the
addition of new features at a later date, e.g. through the use of
hooks, an API or plug-ins.
]]
Unless XML and XML accessories have mangled the English language
totally beyond recognition, that seems a reasonable definition.

> in a universe that is self-consistent, but it's not the one where I

Nor I. 
(I presume anyway - I've never encountered any of those people).

Cheers,
Danny.

[1] http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=extensible&action=Search

-- 

http://dannyayers.com

---

From: Antone Roundy <[email-masked]>
Date: Sat, 8 Jan 2005 17:04:39 -0700

> <geo:coord> for a given <entry>?
Ah, good point--we have indeed built something that isn't a pure tree 
structure, but we haven't explicitly stated anything general about 
whether extensions are allowed to work that way or not.  So do we want 
to say something along the lines of "Except as otherwise provided by 
the Atom specification, elements and attributes affect the meaning only 
of their (immediate?) parent elements.  For example, the values of 
extension elements appearing as children of the feed and head elements 
are not inherited by the feed's entries."  I'd be in favor or some sort 
of language clarifying the point that exceptions to the pure tree 
structure are only allowed where defined by the Atom specification.  If 
we DO want to allow extensions to violate the pure tree structure, we 
should to define a mechanism for doing so such as one (or more) of the 
following:

1) Define a method of explicitly stating that an element appearing at 
the feed level is a default value for entries that don't override it.  
A method of expressing "no value" for arbitrary extension elements, to 
override the default, would be necessary.

2) Define a method of assigning an identifier to an element which could 
be referenced from elsewhere irrespective of the tree structure (RDF 
provides one such method).

3) Have a "mustUnderstand" mechanism, and require any extension which 
violates pure-tree structure to be marked "mustUnderstand".

I think that over time, I've been an advocate of examples of each of 
the foregoing.  Both #1 and #2 would make processing Atom somewhat more 
complex, so I could take them or leave them both without complaint.  I 
don't see a downside to #3 (either for this specific purpose, or more 
generally as a way to avoid misunderstanding of extensions when such 
misunderstanding has potential for causing problems).

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 09 Jan 2005 00:20:33 +0000

Bill de hÓra wrote:

> Look, the point is this. Those arguing from the RDF side of the house do 
> mean what you mean by extensible. Furthermore, what is meant there by 

Dammit. Sorry, that should be, those arguing from the RDF side of the 
house do *not* mean what you mean by extensible.

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 09 Jan 2005 00:18:37 +0000

Tim Bray wrote:
> markup in a feed entry and be confident that it will not cause receiving 
> software to break, and that it will be there for receiving software that 
> actually knows how to deal with it, is what many people describe using 
> the word "extensibility".  I think that Atom is, in a popular usage of 
> the term (a large majority usage, I'd bet, but without backing 
> statistics) extensible.

The ability to add new structures that have not a lot to do with the 
existing structures sounds like modularity. Being able to process what 
is expected to be there in the face of stuff that is not expected to be 
there sounds a lot like robustness.

We could go at this all month. In truth, I have no problem agreeing to 
your use of the term.

> work. 

Look, the point is this. Those arguing from the RDF side of the house do 
mean what you mean by extensible. Furthermore, what is meant there by 
extensible hasn't been demonstrated (in my mind) as a requirement for 
Atom. Thus, in some respects we're having a pointless discussion. One 
side or the other is going to have to give up possession of the term 
extensible, or we're going to continue to watch people talk past each 
other. Once you appreciate that we are talking about two different 
things, execution of the work in hand will become simpler.

cheers
Bill

---

From: Danny Ayers <[email-masked]>
Date: Sun, 9 Jan 2005 01:56:22 +0100

On Sun, 09 Jan 2005 00:18:37 +0000, Bill de hÓra <[email-masked]> wrote:

> Look, the point is this. Those arguing from the RDF side of the house do [not]

I'd be more than happy to use a different term for the
XML-extensibility-like thing which isn't modularity or robustness but
closer to the dictionary definition. Extendibility perhaps?

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Henry Story <[email-masked]>
Date: Mon, 10 Jan 2005 01:20:10 +0100

> <link rel="via" href="..." title="..." length="..." />

Thanks for the question. Let me try the mapping from a graph  
representing that link to the atom xml syntax. Here is how I would  
model that link.

  _e2 --a-----> <Entry>
    |---link---> _l2 ---- a ---> <Link>
                  |--hreflang --> "de"^^xsd:language
                  |--href->  
"http://example.org/de/2003/12/13/Atom03"^^xsd:anyURI

Then I we can follow the recipe [1] to reach our goal

1) Striped RDF/XML + combining multiple descriptions
----------------------------------------------------

<rdf:Description>
    <rdf:type>
      <rdf:Description rdf:about="&atom;Entry">
      </rdf:Description>
    </rdf:type>
    <link>
      <rdf:Description>
        <rdf:type>
          <rdf:Description rdf:about="&atom;Link">
          </rdf:Description>
        </rdf:type>
        <hreflang rdf:datatype="&xsd;language">de</hreflang>
        <href  
rdf:datatype="&xsd;anyURI">http://example.org/de/2003/12/13/Atom03</ 
href>
      </rdf:Description>
    </link>
</rdf:Description>

2) replacing empty property elements with rdf:resource
------------------------------------------------------

<rdf:Description>
    <rdf:type rdf:resource="&atom;Entry"/>
    <link>
      <rdf:Description>
        <rdf:type rdf:resource="&atom;Link"/>
        <hreflang rdf:datatype="&xsd;language">de</hreflang>
        <href  
rdf:datatype="&xsd;anyURI">http://example.org/de/2003/12/13/Atom03</ 
href>
      </rdf:Description>
    </link>
</rdf:Description>

3) Entry Typed Node Element transformation
------------------------------------------

<Entry>
    <link>
      <Link>
        <hreflang rdf:datatype="&xsd;language">de</hreflang>
        <href  
rdf:datatype="&xsd;anyURI">http://example.org/de/2003/12/13/Atom03</ 
href>
      </Link>
    </link>
</Entry>

4) Omitting the Link blank node
-------------------------------

<Entry>
    <link rdf:parseType="Resource">
        <hreflang rdf:datatype="&xsd;language">de</hreflang>
        <href  
rdf:datatype="&xsd;anyURI">http://example.org/de/2003/12/13/Atom03</ 
href>
    </link>
</Entry>

4) Property attributes
----------------------

both hreflang, href and all the other properties of Link are unique,  
and given that they are string literals (subsets of them at least, but  
nevertheless) they can be move into attributes on Link

<Entry>
    <link rdf:parseType="Resource"
          hreflang="de" href="http://example.org/de/2003/12/13/Atom03"/>
</Entry>

5) getting rid of the rdf:parseType
-----------------------------------

This can be done I have been told in the DTD.

<Entry>
    <link hreflang="de" href="http://example.org/de/2003/12/13/Atom03"/>
</Entry>

Henry Story

[1] http://www.w3.org/TR/rdf-syntax-grammar/

> server trusts the client.

I am writing GUI based client software, and I am really looking forward  
to disprove your statement.

> extensions in funny places. Like most people, the server stores  
> standard fields in a relational database, so there are columns for  
> title, summary, etc. in a table called something like  
> "journal_entries". It would be fairly easy to store immediate children  
> of entry in an "unknown_xml" field, and pass them through, but what  
> about the other extensions? Using an RDF store might make this problem  
> a lot easier, but I don't forsee a mass migration in that direction  
> happening this year or next.

You don't need a specialized RDF storage, though very good ones exist.  
There are schemes to map RDF into any relational database, just as  
there are schemes to map objects into relational databases. In fact  
most RDF storage tools in Java provide this.

---

From: Robert Sayre <[email-masked]>
Date: Sun, 09 Jan 2005 19:29:45 -0500

Henry Story wrote:

>>> The question is exactly how should the interesting discovery that 
>>> an  Atom document is an RDF document [Ø] be used to fulfill the 
>>> charter  requirements on extensibility?
>>
>>

...

> and given that they are string literals (subsets of them at least, 
> but  nevertheless) they can be move into attributes on Link
>
> <Entry>

Use of unqualified attributes is deprecated in RDF/XML (check the 
validator). My opinion is that the transformation you're looking for 
would be easier with XSLT.

>>
>>
>> I think the debate is pretty much settled for client GUI software. 
>> RDF  doesn't help a bit. A more interesting situation is a server 
>> receiving  Atom entries to publish. For the purposes of discussion, 
>> let's say the  server trusts the client.
>
>
> I am writing GUI based client software, and I am really looking 
> forward  to disprove your statement.
>

Cool. That's the only way to disprove it ;)

>> "journal_entries". It would be fairly easy to store immediate 
>> children  of entry in an "unknown_xml" field, and pass them through, 
>> but what  about the other extensions? Using an RDF store might make 
>> this problem  a lot easier, but I don't forsee a mass migration in 
>> that direction  happening this year or next.
>
>
> You don't need a specialized RDF storage, though very good ones 
> exist.  There are schemes to map RDF into any relational database, 
> just as  there are schemes to map objects into relational databases. 
> In fact  most RDF storage tools in Java provide this.

That's not my point. My point is that there's a staggering amount of 
data currently living in RDBMSes, and people aren't going to 
re-architect their storage to use Atom.

Robert Sayre

---

From: Danny Ayers <[email-masked]>
Date: Mon, 10 Jan 2005 13:26:12 +0100

On Sun, 09 Jan 2005 19:29:45 -0500, Robert Sayre <[email-masked]> wrote:

To jump in late on -

> re-architect their storage to use Atom.

True, but they don't have to. Taking the RDF case (as something the
far side of Atom+extensions), it's reasonably straightforward to
project RDBMS data as triples, such  as RDF/XML and the representation
of n-ary relations is quite well documented (e.g. [1]). SQL views are
*very* handy.

(Incidentally a simple way of re-architecting would be to replace
existing tables with views that have exactly the same layout,
projected from a triple store/table).

But that's just working on material that's already in the existing
domain of the RDBMS. Where it gets more interesting is with
(potentially unknown) extensions. I reckon it's entirely feasible to
use a triplestore for these bits, leaving the core work to
conventional (existing) tables.

Somewhere around the middle of my to-do list is to take one of the
open source CMSs and add FOAF support. It's easy to imagine a
separate, bolted on RDF store, perhaps using a three-column table in
the existing database. But the tricky (i.e. interesting) part is how
to integrate existing user handling - usernames, access rights etc -
with the new store.

I think the simplest approach would be to cleanly isolate the existing
'username' tables (if necessary) then swap those tables out for SQL
views of a triple table. I've tried stuff similar to this, and it's
pretty straightforward.

What would be better still would be to leave the existing tables
entirely in place, and use joins between those tables and the triple
store. I'm not entirely sure how much work would be involved with this
approach, having yet to experiment.

I reckon in general that the fact that both the RDBMS and RDF are
based on relational models, there's a wide band of overlap that can
simplify interoperability. This isn't really the case with
XML-oriented stores, RDF/XML being a bit of a red herring. It would be
nice for Atom to get the best of both worlds.

Cheers,
Danny.

[1] http://www.w3.org/TR/2004/WD-swbp-n-aryRelations-20040721/
-- 

http://dannyayers.com

---

From: Henry Story <[email-masked]>
Date: Mon, 10 Jan 2005 19:11:32 +0100

Ok, I give up on this task.

I have just found that when there is a rdf:Resource you can't also have 
attributes. And that attributes have to be qualified.

It is a real pity.

It would be good to make a list of what we would have needed from 
RDF/XML to make Atom be rdf, and then work backwards to create RDF/XML2 
where this works out fine.

Henry

On 10 Jan 2005, at 01:29, Robert Sayre wrote:
>> [snip]
>>          hreflang="de" 
>> href="http://example.org/de/2003/12/13/Atom03"/>
>> </Entry>
>
>

You are right. The validator at <http://www.w3.org/RDF/Validator/> is 
really useful.

[snip]

> re-architect their storage to use Atom.

I was not trying to get people to use RDF databases at the back end. I 
was just hoping that a well engineered XML document would with a little 
care also turn out to be a well engineered RDF document. That would 
provide maximum flexibility in that it would allow people to move into 
the rdf world seamlessly.

---

From: "Jeremy Gray" <[email-masked]>
Date: Mon, 10 Jan 2005 10:43:56 -0800

Henry, would you mind sending me a copy of the example you were trying to
work up? I took a scroll through your recent emails to see if I could figure
out which one gave you so much trouble, but I'm not sure if I'm looking at
the right materials or not.

I'm curious because you mention that when there is an "rdf:Resource[sic] you
can't also have 
attributes" which, given that rdf:resource applies only to property
elements, makes sense. As such, I'm wondering what exactly you were trying
to accomplish when you hit your roadblock.

Thanks in advance,

Jeremy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Henry Story
Sent: Monday, January 10, 2005 10:12 AM
To: Robert Sayre; Tim Bray
Cc: [email-masked]; 'Atom WG'
Subject: Re: Atom Link element: Failure

It is a real pity.

Henry

[snip]

---

From: Henry Story <[email-masked]>
Date: Mon, 10 Jan 2005 22:45:51 +0100

Ok, I don't know what happened to me there. I must have been overly 
tired. I went to do some weigh lifting, came back and found that my 
reasoning is in fact correct.

In fact if you put in the following rdf

<?xml version="1.0"?>
<atom:Entry xmlns:atom="http://purl.org/atom/#"
            xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <atom:link
          atom:hreflang="de" 
atom:href="http://example.org/de/2003/12/13/Atom03"/>
</atom:Entry>

in the validator you get the following graph:

which is what I started off with.

Henry Story

On 10 Jan 2005, at 19:11, Henry Story wrote:

> I have just found that when there is a rdf:Resource you can't also 
> have attributes. And that attributes have to be qualified.
>
> It is a real pity.
>
> RDF/XML to make Atom be rdf, and then work backwards to create 
> RDF/XML2 where this works out fine.
>
> Henry
>
>>>> children  of entry in an "unknown_xml" field, and pass them 
>>>> through, but what  about the other extensions? Using an RDF store 
>>>> might make this problem  a lot easier, but I don't forsee a mass 
>>>> migration in that direction  happening this year or next.
>>>
>>>
> was just hoping that a well engineered XML document would with a 
> little care also turn out to be a well engineered RDF document. That 
> would provide maximum flexibility in that it would allow people to 
> move into the rdf world seamlessly.
>
>
>> Robert Sayre
>>
>