Subject: PaceAttributesNamespace is *not* about syntax!

From: Danny Ayers <[email-masked]>
Date: Wed, 26 Jan 2005 11:47:45 +0100

I've added the following note to the Pace:

A lot of the critical response to this Pace has been based on the
assumption that it is about changes to the Atom syntax. Nothing could
be farther from the truth. Within Atom format it will remain mandatory
that documents are produced with no-namespace attributes. This Pace is
about the model.

Resources on the Web are generally given URIs. With RDF, it has been
found useful to also assign URIs to relations, so they too are
uniformly are uniquely defined. As it stands, most of the constructs
and relations within Atom already have URIs - the element names are
namespace-qualified. This isn't the case for the attributes. By saying
that the no-namespace attributes can be interpreted as having names in
the Atom namespace gives them URIs.

As well as simplifying the RDF model the approach described in this
Pace should also be useful for reusing Atom attributes in extensions.

http://intertwingly.net/wiki/pie/PaceAttributesNamespace

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Sam Ruby <[email-masked]>
Date: Wed, 26 Jan 2005 09:03:12 -0500

> http://intertwingly.net/wiki/pie/PaceAttributesNamespace

Let's assume that there will be a non-normative appendix which describes 
the mapping of the Atom/XML syntax to RDF triples (possibly via a 
mapping to RDF/XML or possibly directly).  Clearly, such an appendix 
would need to define a number of relations, and such relations are 
likely to make use of the Atom namespace.

A simple introductory and declarative statement in that appendix that 
describes how such a mapping is done (attribute name + atom namespace) 
would most definately be in order.

But, now lets examine the statement proposed in PaceAttributeNamespace. 
  It essentially alerts producers of something that that they need to be 
aware of.  Now a quesion: what do they need do different with the 
knowledge that the RDF mapping does this?

I would assert the answer to this question is nothing.  Meaning that 
this particular statement is not needed.  Again, no issue with the 
mapping.  No issue with describing the mapping alongside with the actual 
mapping.

- Sam Ruby

---

From: Antone Roundy <[email-masked]>
Date: Wed, 26 Jan 2005 08:05:46 -0700

On Wednesday, January 26, 2005, at 07:03  AM, Sam Ruby wrote:
> Let's assume that there will be a non-normative appendix which 
> describes the mapping of the Atom/XML syntax to RDF triples (possibly 
> via a mapping to RDF/XML or possibly directly).  Clearly, such an 
> appendix would need to define a number of relations, and such 
> relations are likely to make use of the Atom namespace.
>
Agreed.  This issue should be addressed in an appendix rather than in 
the main body of the spec.

---

From: Danny Ayers <[email-masked]>
Date: Wed, 26 Jan 2005 16:57:34 +0100

> mapping.  No issue with describing the mapping alongside with the actual

Although this Pace has been prompted by a desire to help ensure RDF
developers are reading from the same page, it isn't actually tied to
RDF at all. It's about clearly defining terms to assist interop in
general.

I personally think it makes good sense to define terms that appear in
the Atom namespace normatively within the Atom specification. The
argument given above has no effect on that - any part of the
specification could be shifted to 'informative' and the answer to the
question "what do they do different?" would still be "nothing".

It will still be possible to treat Atom as RDF through GRDDL or
whatever, whether the mapping appears normatively in the spec, in an
informative appendix or on the back of an envelope somewhere in Korea.
It will still be possible to add data from other namespaces whether or
not they make sense. It will still be possible to read Atom with
regular expressions. It will still be possible to produce ill-formed
XML and label it Atom.

But there are a lot of places the line could be drawn about what is
normative, right now it's not very far from an RSS 2.1.  Which is a
little disappointing given all the time and effort the WG has spent on
it.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Henry Story <[email-masked]>
Date: Wed, 26 Jan 2005 17:37:58 +0100

On 26 Jan 2005, at 15:03, Sam Ruby wrote:
> [...]
> But, now lets examine the statement proposed in 
> PaceAttributeNamespace.  It essentially alerts producers of something 
> that that they need to be aware of.  Now a quesion: what do they need 
> do different with the knowledge that the RDF mapping does this?
>
> mapping.  No issue with describing the mapping alongside with the 
> actual mapping.

I think your assertion is wrong. If they are consuming or producing 
extended Atom [1]
they will know exactly what these extensions are referring to. It won't
affect in the least consumers of simple, non extended Atom, but it will 
greatly
help consumers and producers of extended atom.

Now if you don't care about making their lives easier, then you have 
nothing
to worry about in this pace. If you do, like I and many others, then 
this will
be very helpful.

> - Sam Ruby

[1] Should we call these molecules?

---

From: Graham <[email-masked]>
Date: Wed, 26 Jan 2005 17:01:43 +0000

On 26 Jan 2005, at 4:37 pm, Henry Story wrote:

> affect in the least consumers of simple, non extended Atom, but it 
> will greatly

What will? To what does "these extensions" refer? How will "it" help 
who? You seem to have given up trying to get your ideas across to other 
people.

(+1 on Sam's argument, btw)

Graham

---

From: Henry Story <[email-masked]>
Date: Wed, 26 Jan 2005 18:11:56 +0100

Graham the Robot [1], when real people come and ask me something I'll 
talk to them.

Henry

On 26 Jan 2005, at 18:01, Graham wrote:
> who? You seem to have given up trying to get your ideas across to 
> other people.
>

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

---

From: Graham <[email-masked]>
Date: Wed, 26 Jan 2005 17:28:10 +0000

Go fuck yourself Henry, you horrible hateful humorless person.

Graham

---

From: Sam Ruby <[email-masked]>
Date: Wed, 26 Jan 2005 21:39:23 -0500

> to worry about in this pace. If you do, like I and many others, then 

It seems to me that you are both misunderstanding and mischaracterizing 
what I am saying. Furthermore, in other emails, I sense a confusion 
between RDF (which is a model) and RDF/XML (which is a syntax).

I am in favor of AtomAsRDF (as a was to model this data).  I am opposed
to AtomAsRDFXML (as a syntax for expressing this model).

If anybody is up to the task, I am for inclusion of prose into the
standard describing how one is to interpret Atom feeds as RDF.  Any such
mechanism that accomplishes this will, by necessity, need to specify
what namespace is used in the URIs used to define relationships.

PaceAttributeNamespace does not do that.  All it says is is that a given
namespace may be used.  For what purpose such a statement is made is
entirely unclear.

By contrast, a precise statement to the effect of how RDF aware tools
MUST interpret Atom feeds if they are to interoperate is both clear and
useful.

- Sam Ruby

---

From: Henry Story <[email-masked]>
Date: Thu, 27 Jan 2005 10:19:47 +0100

Thanks for the reply, Sam.

I think the misunderstanding has mostly to do with the fact that we 
have similar
but slightly different aims. We should try to clearly establish our 
respective aims
and find the points we have in common, so that we can agree to solve 
the points
we have in common quickly and easily.

On 27 Jan 2005, at 03:39, Sam Ruby wrote:
>>> PaceAttributeNamespace.  It essentially alerts producers of 
>>> something that that they need to be aware of.  Now a quesion: what 
>>> do they need do different with the knowledge that the RDF mapping 
>>> does this?
>>>
> It seems to me that you are both misunderstanding and 
> mischaracterizing what I am saying. Furthermore, in other emails, I 
> sense a confusion between RDF (which is a model) and RDF/XML (which is 
> a syntax).

No worry. I think we all know the difference there, but the language 
does lend itself
to confusion.

> I am in favor of AtomAsRDF (as a way to model this data).  I am opposed

Ok. I am in favor of AtomAsRDF(Model) too. But I am trying to go a 
little further
to AtomAsRDFXML (as you put it) because

    - The spec can very nearly already be interpreted that way
    - defining another mapping from xml to RDF, though possible,
      is a lot of work, and we just don't have the time
    - it will allow for the easiest way to explain extensibility of Atom

So though I think (and I have recently myself tried out some ideas on 
this subject)
there may be some general mapping rule from xml to rdf that are much 
closer to the general users intuitions about xml, I think that when the 
xml is written as atom
currently (nearly) is, we have something that does map to a graph and 
that will map
to the same graph  than any more intuitive mapping than rdf/xml would.

> what namespace is used in the URIs used to define relationships.

Well I liked your idea of adding a special section to the spec on how to
interpret atom as rdf/xml, perhaps as part of the extensibility section.
My feeling is that would be best if it explains how atom can be seen to
be rdf/xml, because then explaining extensibility will be very easy:

"any atom document with foreign name spaced attributes or elements must
also be an rdf/xml document when so interpreted"

And we then leave the complexity of that statement to the other specs
out there.

> MUST interpret Atom feeds if they are to interoperate is both clear and

Ok. Well I think we are really thinking very similar thoughts here.

I would just add that we should try to see if the RDF/XML interpretation
of Atom works out, because that will vastly reduce the amount of work we
need to do in explaining the interpretation. ("interpretation" is an
excellent word!)

Henry Story

---

From: Danny Ayers <[email-masked]>
Date: Thu, 27 Jan 2005 14:55:52 +0100

> namespace may be used.  For what purpose such a statement is made is

Ok, maybe a little more explanation is needed in the Pace. The purpose
is to provide global names to the relations expressed by the
attributes.
 
"Global naming leads to global network effects."
http://www.w3.org/TR/2004/REC-webarch-20041215/#identification

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 27 Jan 2005 14:28:09 +0000

> Graham the Robot [1], when real people come and ask me something I'll 

Rudeness objection. I'm seeing genuine questions; fobbing them off (as 
above) is not helping your case.

cheers
Bill

---

From: Sam Ruby <[email-masked]>
Date: Thu, 27 Jan 2005 09:25:42 -0500

> http://www.w3.org/TR/2004/REC-webarch-20041215/#identification

So... define the cases where it MUST be used ... and how ... in order to 
achieve interoperability.

If the desire is to "provide global names to the relations expressed by 
the attributes", then it would make sense to describe what namespace 
MUST be used for such relationships.  Perhaps in the portion of the 
document which describes how one is to infer such relations from the raw 
xml attributes.

- Sam Ruby

---

From: Henry Story <[email-masked]>
Date: Thu, 27 Jan 2005 16:49:29 +0100

On 27 Jan 2005, at 15:28, Bill de hÓra wrote:
> Rudeness objection.

One reaps what one sows. [1]

>  I'm seeing genuine questions

Since you are asking, I'll answer them.

> who?

Consider the problem of creating extensions to Atom. You are adding a 
new
vocabulary to the current atom vocabulary, so you will have non atom 
name
spaced elements or attributes in your extended atom document.

<feed>
	<entry>
		<title>Atom Robots run amok</title>
         <link href="http://example.org/"/>
		<my:illustration my:href="http://bblfish.net/blog/img.jpg">
         ...
     </entry>
</feed>

We are all agreed about what the above document means, stripped of
the my:illustration tag. Parsers that only wish to concern themselves 
with
those striped documents will have no trouble. The spec clearly 
specifies what
is what.

The problem is to clearly specify how extended atom documents like the 
one above
are to be written consistently, so that they can be interpreted 
correctly, the
way the writer of the document intended them to be.

> To what does "these extensions" refer?

These extensions refer to attributes such as my:href in the example 
above.

> How will "it" help who?

The problem is that attributes in atom are not namespaced. If they were 
then it
would be easy to interpret the above document as an rdf document. An 
rdf document
has very clearly specified semantics. Having these clearly specified 
semantics is
very helpful to extension writers and consumers.

The details of how it will help are much more difficult to explain in a 
short
e-mail such as this. A hint is contained in the word "onotology". This 
has to do
with Objects. And there is a very strong relationship between OO 
programming and
  what is being proposed here. The benefits of OO programming are the 
same benefits
we stand to gain here: it makes it much easier to create elements and 
specify how
they can be combined.

But it would perhaps be best to work through an example to help show 
how this
works.

Does this help?

Henry Story

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

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 27 Jan 2005 17:12:21 +0000

> One reaps what one sows. [1]

Should I counter by quoting from the Sermon on the Mount?

> way the writer of the document intended them to be.

This might be over-egging it, but... I would say the above is not an 
extension to Atom (no new Atom names have been added).

What would be good is a controlled way to associate new properties from 
whatever vocab to the entry, either as metadata (aboutness) or data 
(partness).

An RDF mapping will provide that, but I'm not clear it needs to be part 
of the Atom format, since there doesn't seem to much demand for anything 
other than the ability to structurally add properties (via namespaces) 
outside the RDF community.

OT: the single concern I have with Atom in this area is the link 
element, specifically @rel. Extension by attribute is an XML antipattern 
as best I can tell, and @rel strikes me as being bindweed rather than 
letting a thousand flowers bloom. Having said that, the market is 
innovating beyond what we're speccing here, so perhaps we should just 
stay out of the way.

> would be easy to interpret the above document as an rdf document. An rdf 
> document

Is this not solvable by articulating how the RDF mapping should treat 
Atom specified (unprefixed) attributes and constraining future 3rd party 
attribute extensions to use a prefix?

> Does this help?

Yes, but I think it can be dealt with as outlined above, unless I'm 
missing something.

cheers
Bill

---

From: Danny Ayers <[email-masked]>
Date: Thu, 27 Jan 2005 20:38:40 +0100

> Should I counter by quoting from the Sermon on the Mount?

Blessed are the feedmakers.

> whatever vocab to the entry, either as metadata (aboutness) or data

Yep, that's essentially what I've been chasing all along.
 
> outside the RDF community.

Yes and no - there is demand for this kind of thing, is the RSS 1.0
community the same as the RDF community? There's a lot of additions
around there... Whatever, even with RSS 2.0 there's Easy News Topics
and all the stuff associated with media (enclosures + Yahoo's
extensions) as good examples.

> innovating beyond what we're speccing here, so perhaps we should just

Hmm, maybe, but if the Technorati stuff and even rel="nofollow" are
anything to go by, the bindweed can carry low-hanging fruit.

> attribute extensions to use a prefix?

(Presumably also barring 3rd parties from reusing Atom attributes in
those extensions).

My concern there is with extension development outside of the RDF
community. Without some uniform interpretation of the attributes
outside of the context of an Atom document, there's scope for unwanted
interactions. Assigning the things global names (URIs), even if they
aren't explicitly expressed in Atom documents seems a low cost
solution.
 
> Yes, but I think it can be dealt with as outlined above, unless I'm

Non-RDF extensions.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 27 Jan 2005 20:49:12 +0000

> extensions) as good examples.

Is the RSS1.0 community relevant, given RSS1.1? I'm sincere in asking this.

>>Yes, but I think it can be dealt with as outlined above, unless I'm

As I've said, I'm not seeing the demand for uniform evaluation outside 
an RDF context.

cheers
Bill

---

From: Danny Ayers <[email-masked]>
Date: Fri, 28 Jan 2005 00:15:01 +0100

> Is the RSS1.0 community relevant, given RSS1.1? I'm sincere in asking this.

Dunno really. There are an awful lot of RSS 1.0 feeds out there -
you've got one, I've got one. If rss-dev give the green light to 1.1,
I'll probably changeover before long, though the extensions (FOAF,
Geo) I've got in place aren't likely to change.

> As I've said, I'm not seeing the demand for uniform evaluation outside

Outside of the [insert Brayism about architects], demand for
uniformity is generally thin on the ground around syndication (<guid>s
ring a bell?). But that doesn't reduce its benefits, usually
uniformity leads to a net cost reduction, don't you reckon? Standards
and all that?

Cheers,
Danny.

-- 

http://dannyayers.com