Subject: RSS extensibility

From: Danny Ayers <[email-masked]>
Date: Fri, 7 Jan 2005 14:48:56 +0100

In the interests of clarification, consider this pseudo-Atom snippet,
with an extension:

<feed "http://purl.org/atom/ns#
xmlns:prism="http://prismstandard.org/namespaces/1.2/basic/">

<entry>
   <prism:embargoDate>2005-02-15</prism:embargoDate>
...
</entry>

</feed>

Looking at the PRISM spec (which the namespace qualification identifies) -
[[
embargoDate
Earliest date (potentially including time) the resource may be used
according to the rights agreement, or clause in the rights agreement.
]]

So the human meaning of an 'embargoDate' element is reasonably clear.
The problem is that with RSS 2.0's approach to extensibility, there is
no relationship defined between this element and any part of the feed
data. Ok, it's an embargo date. But the embargo date of what?

On the other hand, following the RSS 1.0 approach to extensibility,
the markup would be interpreted as RDF/XML, which assigns a role for
the different parts of the XML structure. The pseudo-Atom is making
the statement:

_:entry prism:embargoDate "2005-02-15" .

The embargoDate is unambiguously a property of the entry. In the RSS
1.0 case this is defined in the RDF model.

IMHO Atom would benefit from a similar disambiguation mechanism. 

As Henry has suggested this could be through RDF, mapping directly
between the Atom syntax and an RDF representation. This does seem the
easiest way of giving Atom such a mechanism without using RDF/XML. But
an Atom-specific mechanism could relatively easily be defined. The use
of URIs for entries is a good start, but other structural hooks (which
could make sense of the example above) could be added without any
disruption of the core spec as it stands (aside from constraining how
and where such extensions should appear).

This general idea has been the subject of several proposals, including
Sean Palmer's ExtensibilityFramework early on and the more recent
properties-based approach (sorry, not got links, the Wiki is giving me
500s).

I believe the basic extensibility mechanism should be part of the core
spec, though any mapping to RDF might be provided as 'informative'.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Antone Roundy <[email-masked]>
Date: Fri, 7 Jan 2005 08:38:07 -0700

Thanks for the example--very clear.  It seems to me that there are two 
ways to look at this:

1) To a human looking at the XML (at least to one who doesn't see 
through RDF-colored lenses (which, BTW, is in no way intended as a 
pejorative--maybe it's everyone else's lenses that are colored)), I 
think it's intuitively obvious that it's the embargo date of the entry.
2) However, technically, nothing in the spec explicitly says that 
that's the case.

I suspect that #2 is important to many of us, but that many others of 
us don't care about #2, because #1 is sufficient for us.  I also 
suspect that the former will not be made to cease caring and that the 
latter will not be made to begin caring by any amount of discussion.  
This brings us back to the question of how to serve the needs of both 
groups.  Can Atom be made RDF (or can we agree that it already is 
RDF...and can RDF processing tools handle it as such) with minimal 
syntactic overhead and no risk of XML structure requiring an RDF-aware 
parser?  Or (ignoring the possibility of other approaches) can we make 
Atom extremely easy to convert to RDF without ambiguity like what is 
mentioned below?

---

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

> data. Ok, it's an embargo date. But the embargo date of what?

The embargo date of the entry.  This seems painfully obvious, and any 
other reading would be willfully contrary.  Either software understands 
what embargoDate means or it doesn't, and if it does, well then, it'll 
embargo the entry, and if not, not.

I have not seen any evidence that these RDF incantations have any 
relation to the needs of implementors. -Tim

---

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

On Fri, 07 Jan 2005 07:44:46 -0800, Tim Bray <[email-masked]> wrote:
> other reading would be willfully contrary.  

To you maybe, but how are applications to know that?

Either software understands
> embargo the entry, and if not, not.

But it isn't that black and white. The software may understand that
embargoDate is a property of the entry, without knowing anything about
embargos. This is useful information, especially if you wish you want
to merge data from disparate sources (and possibly republish), an
scenario that's becoming more widespread in syndication.

> relation to the needs of implementors. -Tim

Now that really is wilful contrariness. I made a comparison between
the approach to extensibility taken by RSS 1.0 and RSS 2.0. I
suggested that RSS 1.0 had advantages that would benefit Atom. I also
suggested that RDF wasn't needed for Atom to enjoy those advantages.
Where are the incantations?

I can find more evidence of the utility of RSS 1.0's approach if
necessary, but I would have hoped that contributors to this project
will have done some research into what application implementors are
doing with RSS 1.0. Quick quote:
[[
As a science publisher, however, we are minded to continue to produce
RSS 1.0 for the immediate future, since it meets all our current
needs, while monitoring the Atom development to see what end utility
it might afford. Our current view is that Atom does not provide the
necessary level of metadata extensibility and interoperability that we
are able to achieve with RSS 1.0.
]]
http://dlib.anu.edu.au/dlib/december04/hammond/12hammond.html

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Tim Bray <[email-masked]>
Date: Fri, 07 Jan 2005 11:50:49 -0800

...
>>>  Ok, it's an embargo date. But the embargo date of what?
>>

I think we must live on different planets.  If I propose an extension, 
e.g. embargoDate, and I want anyone to use it, then I'm going to have 
to specify how it works.  E.g. "<prism:embargoDate> can appear as a 
child of <atom:entry> and it gives the embargo date for the entry..."  
Software which wants to *operate* on this is going to have to know 
these semantics.  Software which does not know the semantics can do 
exactly nothing useful, aside from either ignore it (typical for 
clients) or copy it through (typical for middleware).

I'm sorry, the assertion that it's not clear what's going on the 
example above is just incomprehensible to me. -Tim

---

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

On Fri, 07 Jan 2005 11:50:49 -0800, Tim Bray <[email-masked]> wrote:
> I think we must live on different planets.  

All I'm suggesting here is making the part you called "painfully
obvious" explicit.

If I propose an extension,
> child of <atom:entry> and it gives the embargo date for the entry..."

True.

> these semantics.  

Not entirely true. 

Software which does not know the semantics can do
> clients) or copy it through (typical for middleware).

The software may not know all the semantics and still do something useful.

> example above is just incomprehensible to me. -Tim

In your example you are giving a specific meaning to this specific
parent-child relationship within the Atom format. You are describing a
relationship between entities - the entry is one entity, the date
another, and the relationship is that the second is the embargoDate of
the first.

Ok, now what if the Atom spec said that all child elements of <entry>
are to be considered to be characteristics of that entry, with the
value of those characteristics being given by the content of the
child.

This would mean that in your specification you'd only have to state
the specific meaning of "embargoDate", not how the structure should be
interpreted. The entity-relationship model would be consistently
mapped from the syntax across all extensions. Like having a light
schema to work from. One less job for you, the extension developer.
It's also one less job (per extension) for every single developer that
wishes to support extensions. This particular part of their code would
only have to be written once.

It also enable consumers of this data to answer questions like  "what
is this entity related to?" without knowing the details of specific
extensions. If those are other resources with that can potentially be
very useful in a place like the Web.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: David Powell <[email-masked]>
Date: Fri, 7 Jan 2005 20:45:37 +0000

> example above is just incomprehensible to me. -Tim

A couple more examples:

An entry has an ex:digitalSignature property.  This is intended to be
a digital signature of that exact instance of an atom entry.

The entry is annotated using an atom:origin element, and republished
by a Planet*-type site.

Because the subject of the property wasn't communicated explicitly,
then this property has been republished resulting in an incorrect
signature. If there was a way to tell whether a property applied to an
entry directly, then it would be safe for the republisher to republish
all properties of the entry, even if they were extensions whose
meaning wasn't known to the republisher.

Another example might be a property such as ex:rating, intended to
provide slashdot-style ratings specific to the community of readers of
that feed. If those entries are republished, then the original ratings
shouldn't be republished in the aggregate feed.

HTTP has the same extensibility problems. Of 4 different types of
header, only entity headers can be extended unless you wait for
HTTP/2.0. [1] At least HTTP makes this limitation clear.

Whether or not we involve RDF, we probably need to be clear about what
properties implicitly apply to; in the least ambitious case, by doing
what HTTP does: "all extensions apply directly to the content,
properties of entities such as the physical representation of the
content cannot be described by extensions".

If we decide that extensions such as the two above are not allowed in
Atom, that is better than saying nothing.

[1] RFC 2616; sections 4.5, 5.3, 6.2, and 7.1

-- 
Dave

---

From: Antone Roundy <[email-masked]>
Date: Fri, 7 Jan 2005 14:21:49 -0700

...
> The software may not know all the semantics and still do something 

Could you give an example of something useful that a real world 
application would be enabled to do?

> value of those characteristics being given by the content of the

Just for clarification, would that preclude things like the following, 
where the child element of <entry> has child elements?

<entry>
	...
	<ext:image>
		<ext:url>http://www.x.com/img.jpeg</ext:url>
		<ext:height>30</ext:height>
		<ext:width>40</ext:width>
	</ext:image>
</entry>

> only have to be written once.

Off the top of my head, I can't imagine how this would impact the 
amount of code required in an application.  Could you elaborate?

---

From: Antone Roundy <[email-masked]>
Date: Fri, 7 Jan 2005 14:28:33 -0700

> shouldn't be republished in the aggregate feed.
Are you saying that RDF could help with this situation?  If so, could 
you explain how?

---

From: Tim Bray <[email-masked]>
Date: Fri, 07 Jan 2005 13:36:43 -0800

> value of those characteristics being given by the content of the

Would you be satisfied with a paragraph that says that those who extend 
Atom may do so by putting in namespaced elements, and that such 
elements, when the information they contain is relevant to an entry, 
SHOULD appear as a child of atom:entry?

And I suppose a similar paragraphs concerning atom:feed?

-Tim

---

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

> And I suppose a similar paragraphs concerning atom:feed?

I think having something along those general lines would be
significantly better than the current situation. Obviously I can't
speak for anyone else, but if most people were happy with it, I would
be too.

Cheers,
Danny.

-- 

http://dannyayers.com

---

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

> Are you saying that RDF could help with this situation?  If so, could

Tim was saying that it was obvious that embargoDate applied to the
entry, I was trying to highlight situations where it isn't obvious
what object a property is referring to, because the "entry" is quite a
complex thing.  It can have multiple versions, it can be republished
in different feeds etc.

I think those situations are both quite difficult, if we spent a long
time thinking about it, then we probably could develop some way to
identify different concepts, the properties that apply to them, and
how these concepts should be processed and propagated by applications.

But I think that would be very hard, and a simpler alternative would
be just to limit Atom extensions to implicitly being properties of
entries, feeds, etc; but to precisely define what we mean by those
terms.

Either way is RDF-friendly, we are still talking about objects and
properties. The current situation isn't quite RDF-friendly though,
sub-elements of an entry can be referring to all sorts of different
concepts, and without knowing the extension, you can't know what. It
would be possible for extensions to be defined such as my two examples
where it is not safe for properties to be republished, because they
are not solely properties of the entry.

I think that aspects of the RDF model are useful, especially wrt.
extensibility. Most of these aspects won't really make much
difference, if any, to how Atom looks, but might help the
interoperability of Atom extensions, and would probably make Atom
close enough to the RDF model, that it would be easy to produce a
mapping - even if that mapping is produced outside of the WG.

See my post to the "Atom extensibility" thread.

-- 
Dave

---

From: Danny Ayers <[email-masked]>
Date: Fri, 7 Jan 2005 23:53:35 +0100

> application would be enabled to do?

Off the top of my head, how about categorizing entries by their properties. 
But being able to mix extensions in a predictable fashion is generally
nice to have. Last time I looked my own RSS 1.0 feed was using terms
from 9 namespaces (mostly through the FOAF output plugin). I could
merge with lots of other peoples RSS 1.0 feeds and be sure all the
same information would still be available. If it wasn't mapped to a
common model (through the structure) I wouldn't even know how to
merge.

>                 <ext:width>40</ext:width>

I would expect this to be possible, but the details need to be worked
out (i.e. does the parent-child relationship thing go all the way
down? - I'd expect not).

> amount of code required in an application.  Could you elaborate?

Ok, say x,y come from one extension (geo) and magnitude another
(seismo). The client receives something like this:

<entry>
   <geo:x>10.1</geo:x>
   <geo:y>57.3</geo:y>
   <seismo:magnitude>7</seismo:magnitude>
</entry>

a bit of code could pick these values up with characters[] in SAX or a
text node in DOM or whatever XOM sees, but the thing is both geo and
seismo are following the same structure

but if geo and seismo did things a little differently:

<entry>
   <geo:coords x="10.1" y="57.3" />
   <e:magnitude>7</e:magnitude>
</entry>

a bit of code could pick the magnitude value up as before, but the
coords would need different handling - SAX would have to go poking in
attributes, DOM would need a getAttribute(), XOM would - ok, I've no
idea, but I expect something different.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: "Roger B." <[email-masked]>
Date: Fri, 7 Jan 2005 17:25:22 -0600

> SHOULD appear as a child of atom:entry?

Tim: +1, for the sake of compromise if nothing else.

Although y'know, having spent some time watching the podcasting crowd
develop, I'm beginning to think such a clarification might even be
necessary. I'm seeing folks wanting to shove all kinds of stuff into
rss:item that actually has nothing to do with the conceptual item.
Atom should probably head that impulse off at the pass.

--
Roger Benningfield
blog: http://admin.support.journurl.com/

---

From: Antone Roundy <[email-masked]>
Date: Fri, 7 Jan 2005 16:39:41 -0700

> Off the top of my head, how about categorizing entries by their 

I don't understand.  Could I get some example XML, and if the XML 
doesn't make it obvious, an explanation of how RDF makes this possible 
where it's not possible lacking RDF?

> common model (through the structure) I wouldn't even know how to

Again, I don't understand.  When you talk of merging feeds, do you mean 
making a feed out of entries from separate feeds (but where the entries 
themselves are not altered), or merging the entries themselves, where 
sometimes the feeds contain different instances of the same entries, 
resulting in entries containing more data than exists in any one feed?  
Either way, what information might become unavailable in the process?  
Maybe once I understand the foregoing, I'll also understand "mapped to 
a common model (through the structure)".

> idea, but I expect something different.
Let me see if I've got this right: you're saying that by standardizing 
on putting data in element content vs. in attributes, the code would 
only have to support getting values from element content, and not have 
to bother with getting attributes?  Having typed that sentence, it 
seems I must be missing something, because the following pseudocode 
snippets seem only trivially different to me:

geox = GetElementContent("/geo:x");
geoy = GetElementContent("/geo:y");
magnitude = GetElementContent("/seismo:magnitude");

geox = GetAttribute("/geo:coords/@x");
geox = GetAttribute("/geo:coords/@y");
magnitude = GetElementContent("/seismo:magnitude");

I'm assuming the client knows something about the geo and seismo 
extensions--otherwise, I can't imagine what the client would be doing 
with the extension elements anyway (beyond ignoring it, storing it in 
an "unknown extension" table, or passing it through to some other 
application).

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 7 Jan 2005 17:57:35 -0800

>    <prism:embargoDate>2005-02-15</prism:embargoDate>

A properly defined metadata specification would not define such
as an element, but rather as an attribute on the entry element.
The reason it is an element in PRISM is because that namespace
is intended for RDF descriptions, which are themselves a case of
third-party metadata assignment, not mark-up design.

> according to the rights agreement, or clause in the rights agreement.

And it also says

  7 Sharp-eyed readers familiar with RDF may have noticed that the
    RDF subject of the embargoDate and expirationDate elements is not
    the Corfu photo, but an anonymous node. That is because those
    elements do not directly describe the photo. Instead, their
    interpretation is that the agreement governing the use of the
    photo imposes such a condition. This interpretation is also used
    in the geography, industrySector, and usage elements shown in the
    next example.

> 1.0 case this is defined in the RDF model.

No, it isn't, as is clear from the PRISM specification itself.  XML
does have a built-in containment relation, which is the essence of a
mark-up language.  RDF/XML does extra work to override that containment
relation for the sake of externally-defined metadata.  What you ascribe
to RDF's inherent characteristics is, in fact, the opposite -- it is
XML's native characteristics that are escaped by RDF/XML.

Poorly targeted RDF mark-up will be just as vulnerable to 
misinterpretation
as poorly designed XML mark-up, whereas properly designed XML mark-up is
syntactically bound through containment to the resource it refers.  
E.g.,

    <entry other:embargoDate="20050202">stuff to be embargoed</entry>

XML does have a natural containment relationship that is only violated
by specific types of languages that do not actually perform mark-up,
namely RDF and its siblings.  While I don't see any reason not to make
XML's mark-up relations explicit in the specification, I do hope that 
folks
understand that the relationship should be obvious to anyone who does 
not
work in a language that is as perversely non-mark-up as RDF/XML.

....Roy

---

From: Eric Scheid <[email-masked]>
Date: Sat, 08 Jan 2005 13:26:40 +1100

>>    <prism:embargoDate>2005-02-15</prism:embargoDate>

how about a different example

<entry>
    <qaz:authorRank>17</qaz:authorRank>
    ...
</entry>

---

From: Danny Ayers <[email-masked]>
Date: Sat, 8 Jan 2005 10:59:12 +0100

> where it's not possible lacking RDF?

Say your system is aggregating material from two sensors, and you get
the following, one from each:

<entry>
  <id>http://123</id>
  <date>2005-02-02</date>
  <geo:x>10.1</geo:x>
  <geo:y>57.3</geo:y>
</entry>

<entry>
  <id>http://123</id>
  <date>2005-02-03</date>

It isn't clear how these should be merged - does the entry with the
later date replace the earlier one? The (presumably) desired behaviour
is for the geo+seismo properties all to appear as elements under
(properties of) the entry. Mapping syntax to a model can help decide
what to do  *in the general case* rather than per-extension. As it
happens, RSS/RDF would only go part of the way with something like
this - you'd get the desired merged entry, but with two dates.

> a common model (through the structure)".

There is a predictable way of being able to combine *any* two RDF/XML
documents,  whatever vocabularies are used. XML alone doesn't provide
this.

> magnitude = GetElementContent("/seismo:magnitude");

Yes, trivially different, two extra lines of code. Potentially for
every developer, for every extension.

> an "unknown extension" table, or passing it through to some other

The 'what to do with unknown extensions' question is something that
makes a lot more sense if you have commited to the full RDF model. For
example, your system might have a piece of data stored:

<entry>
...
   <xxx:wibble>John Smith</xxx:wibble>
</entry>

You might later pick up the statement:

<xxx:wibble>
   <owl:sameAs rdf:resource="http://purl.org/atom/ns#contributor" />
</xxx:wibble>

So your system would know to list anything marked xxx:wibble along
with the other contributors.

Cheers,
Danny.
-- 

http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Sat, 8 Jan 2005 11:21:29 +0100

On Fri, 7 Jan 2005 17:57:35 -0800, Roy T. Fielding <[email-masked]> wrote:

>   7 Sharp-eyed readers...

I was only providing an example for demonstration purposes. Broad brush strokes.

> XML's native characteristics that are escaped by RDF/XML.

Perhaps I wasn't clear enough. XML has containment. Individual
specifications may assign it semantics. RDF/XML assigns it semantics
corresponding to the RDF model. Without either the individual
specification's definition, or a generalised interpretation like
RDF/XML's all you have is syntax featuring containment.

> namely RDF and its siblings.  

But XML containment can only express tree structures. To express graph
structures, the containment must somehow be violated. RDF is a graph.

(RDF/XML could probably have made a lot better use of XML's structure,
but it's a bit late in the day now).

While I don't see any reason not to make
> XML's mark-up relations explicit in the specification, 

That pleases me. That's all I'm hoping for.

I do hope that
> work in a language that is as perversely non-mark-up as RDF/XML.

Well there you have it - it is possible to design XML languages that
are perverse. So we can't rely on everyone following the 'obvious'
relationship pattern. Making it explicit should help prevent
misinterpretation.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: David Powell <[email-masked]>
Date: Sat, 8 Jan 2005 12:00:19 +0000

> this - you'd get the desired merged entry, but with two dates.

I think that reason that RDF is only helping partially here is that
you have a simplified model of an entry that is actually only
modelling the state of an entry at a point in time, when actually
entries are expected to vary over time and have multiple instances.

This is fine, it is a useful simplification; models are supposed to be
simplifications.

But you can't then expect to merge two different instances of the
entry under this model using simple RDF graph merging, because the
model is an over-simplification.

Eg: If you merged:

<entry>
  <id>http://123</id>
  <date>2005-02-03</date>

and

<entry>
  <id>http://123</id>
  <date>2005-02-04</date>
  <seismo:magnitude>7.5</seismo:magnitude>
</entry>

... you would get:

<entry>
  <id>http://123</id>
  <date>2005-02-03</date>
  <date>2005-02-04</date>
  <seismo:magnitude>7.5</seismo:magnitude>
  <seismo:magnitude>7</seismo:magnitude>
</entry>

Not very useful.

A solution for RDF-based applications wanting to merge incoming RSS
and get a consistent RDF model is to either have special
application-level merging logic that knows about the simplification
that has been made; or to have a model where instances of an entry are
modelled explicitly. If the instances have ids, then you can allow for
both posting new instances of entries, and annotating existing
instances with extra information. Its a tradeoff between flexibility
and complexity.

-- 
Dave

---

From: Danny Ayers <[email-masked]>
Date: Sat, 8 Jan 2005 13:30:13 +0100

On Sat, 8 Jan 2005 12:00:19 +0000, David Powell <[email-masked]> wrote:

 Its a tradeoff between flexibility
> and complexity.

Indeed. There was recently some coverage on-list about using a richer
model (in RDF), specifically to preserve provenance.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Henry Story <[email-masked]>
Date: Sat, 8 Jan 2005 16:00:19 +0100

I think this is a very nice example, and will show the power of seeing 
atom as RDF. If we accept that the atom syntax is an RDF syntax [Ø] 
then we can draw the two entries in the ascii graph notation [1] as 
follows.

_f1 ---is a---> <Feed>
  |----head---->  ....
  |----entry---> _e1 --is a---> <Entry>
                  |----id-----> <http://123>
                  |---date----> "2005-02-02T13:05:04"^^xsd:dateTime
                  |---geo:x--->"10.1"
                  |---geo:y--->"57.3"

_f2 ---is a---> <Feed>
  |----head---->  ....
  |----entry---> _e2 --is a---> <Entry>
                  |----id-----> <http://123>
                  |---date----> "2005-02-03T07:05:04"^^xsd:dateTime
                  |---seismo:magnitude--->"7"

let us take the point of view now of a simple machine confronted by 
these two entries. Should it merge these two entries or should it leave 
them as separate?

The machine that parses this could now look up the atom owl document 
located at the atom name space location, where it would find out that 
the <atom:id> and the <atom:date> relations are functional [2], so can 
only have one value. Since _e1 and _e2 are related to different dates 
it follows that _e1 and _e2 are not the same and so should not be 
merged.

Now the problem with the graph above, is that it does not make sense to
assign a geo location to an entry. This will probably not be allowed by 
the geo ontology, which will probably specify some location class to be 
the the subject of such a relation. One may want to imagine some weird 
monster called a Entry-geolocation, but it will have all kinds of weird 
properties. So let us be throw that monster out of the window, even 
though it makes xml sense: it does not make any other sense at all.

This is probably what was meant:

_f1 ---is a---> <Feed>
  |----head---->  _h1
  |                |---author-> _p1 ---is a---> <Person>
  |                              |----email---> [email-masked]
  |
  |----entry---> _e1 --is a---> <Entry>
                  |----id-----> <http://123>
                  |---date----> "2005-02-02T13:05:04"^^xsd:dateTime
                  |--content--> _p1 ---is a ---> <foaf:Person>
                                 |--foaf:home--> _loc ---is 
a---><geo:Location>
                                 |                |---geo:x--->"10.1"
                                 |                |---geo:y--->"57.3"
                                 |--foaf:mbox--> 
<mailto:[email-masked]>

_f2 ---is a---> <Feed>
  |--head-->  ....
  |--entry-> _e2 --is a---> <Entry>
              |----id-----> <http://example/123>
              |---date----> "2005-03-02T07:05:04"^^xsd:dateTime
              |--content--> _event1 ---is a ---> <phy:Event>
                           
|--phy:date-->"2005-02-02T13:05:04"^^xsd:dateTime
                           |--phy:loc---> _loc2 --is a ---> 
<geo:Location>
                           |               |--geo:x-------> "10.1"
                           |               |--geo:y-------> "57.3"
                           |--seismo:magnitude-->"7"

So here again the machine can see that it has two entries. Since _e1 
and _e2 have different dates and different ids. But the machine can go 
on its merry way and deduce some other interesting things. It can take 
notice that the location of the
home of person _p1 is the same as the location of _event1. It knows 
this because
by downloading the OWL ontology description of the geo ontology it will 
find that the geo:x and geo:y properties are functional too, and that 
combined they are inverse functinal.[3] So it knows that _loc1 and 
_loc2 are the same. These can then be merged. As a result it knows that 
_event1 occurred at the location of the home of person _p1. It still 
does not know that this occurrence was at at time during which _p1 had 
his home there. Perhaps another entry somewhere else will have that 
information. Perhaps somewhere else there would be foaf:knows 
information that relates the author of the feed _f1 to _p1, and this 
would be again some very useful information.

Ok. So what can we deduce from the above:
    - it is possible to have nonsensical but well formed xml
    - well defined Ontologies can help create extensions to atom that 
make sense
    - These ontologies then allow certain deductions to be made by in 
the know software that can be very valuable.

Henry Story

[0] http://www.imc.org/atom-syntax/mail-archive/msg11850.html
[1]  one does not have to understand graph theory to understand this, 
just as one does not have to understand set theory to check that one 
has been given the correct change.
As a notational convention variables such as _f1 and _f2 are blank 
nodes. <Entry>, <Feed>, <http://123> are URIs. ----date----> is a 
directed relation between the Node on the left and the node on the 
right which as a url of
atom:date.
[2] functional in the same way as f(x)=y means that for all x there is 
only one mapped y. If f is the times 2 function the f(7)=14. This is 
why the square root function only covers positive real numbers because 
if it did not it would not be functional and sqrt(-4) = -2 and +2
[3] I am not sure this can be defined as it stands in OWL, but clearly 
it could.

---

From: "Roger B." <[email-masked]>
Date: Sat, 8 Jan 2005 09:47:47 -0600

> atom as RDF.

Henry: I hope it isn't too depressing to know that, at least for this
individual, it really doesn't. To me, you've just sketched out a
solution in search of a problem... there are far, far easier ways of
getting the same results.

Like, say, putting the geo and seismo data together in the entry to
begin with. After all, absent a signing mechanism, merging two entries
with the same atom:id is only going to get you in trouble. It'd be far
simpler for the publisher of Feed A and Feed B to just do any merging
on her own (she doesn't need a machine to deduce any relationships
within her own data, after all) and produce a Feed C that saves
everyone the trouble.

> Should it merge these two entries or should it leave
> them as separate?

In my case, the later entry is ignored... existing entries are never
updated once they're in the database. A different app would probably
either (a) completely overwrite the old entry with the new one, or (b)
declare them to be two distinct versions of the same entry.

In any case, there's little pressing need to try and create a
Frankenstein's Entry from the two.

--
Roger Benningfield

---

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

> SHOULD appear as a child of atom:entry?

Replace 'extend' with 'add information' and I'm +1.

cheers
Bill

---

From: Henry Story <[email-masked]>
Date: Sat, 8 Jan 2005 17:58:59 +0100

On 8 Jan 2005, at 16:47, Roger B. wrote:
> getting the same result

Which result? I showed many different things...

  0) I had previously already shown that one can see Atom to be RDF, 
without any
     syntax changes.

  1) I showed that seeing Atom as RDF makes it easy to structure atom 
extensions.
     It gives us a framework for making intelligent extension decisions.

  2) I showed also how one could use the rdf graph information and owl 
information
     to make decisions on how to merge some information and make 
deductions on
     that information.

  3) I also showed how one could have nonsensical yet well formed xml, 
and how
     thinking in terms of ontologies (very similar to class diagrams in 
OO
     programming) made this much more apparent.

Clearly there is nothing complicated about 0) above. For those that 
don't care about RDF, ie: most simple aggregators at first, they won't 
need anything more than a simple xml parser. For them there is nothing 
to it. They can just ignore anything that is outside the atom 
namespace.

I think for the rest of the points above the argument is pretty much 
the same. If you don't want to create extensions, having a framework 
with which to do them won't be of any interest to you. But for those 
who do it makes a *huge* difference. For those that don't care to 
reason about the data the structure made available by rdf is not of 
great interest. But that does not make it not useful to others.

You can look at the web with a black and white browser, and not care 
about color tags in your html. That was not a reason for excluding 
color tags from the spec.

> within her own data, after all) and produce a Feed C that saves

I can't at the same time show how you can do deductions and also show 
how one sets up a trust network, and everything else that entails in 
one e-mail...

> declare them to be two distinct versions of the same entry.

In BlogEd I do (b) and what you do. IE. I never change an entry in the 
database and I would declare them to be different version of each 
other. Ie: I have two entries pointing to the same EntryID, which is 
exactly what the spec says.

> Frankenstein's Entry from the two.

I don't think you understood what I was trying to say in my mail there. 
Perhaps I was not clear.

I showed how one could use machine readable information to deduce that 
the two entries should not be merged. This deduction could be done by a 
machine using that data of course or simply hardcoded by a human 
programmer who wrote the storage layer. That is indeed the correct 
behavior and it is the one that your program exhibits (it throws one 
entry away, but what you do with your data is completely up to you)

The "Frankenstein Entry" was in relation to this graph:

_f1 ---is a---> <Feed>
  |----head---->  ....

in particular this subgraph:

                 _e1 --is a---> <Entry>

which corresponds to the xml

<entry>
   <id>http://123</id>
   <date>2005-02-02</date>
   <geo:x>10.1</geo:x>
   <geo:y>57.3</geo:y>
</entry>

Here our RDF model (or Tim Bray's intuition) would say that the geo:x 
and geo:y
properties are properties of _e1. That means that _e1 has to be some 
thing of type Geographical Position. _e1 would then be a thing of type 
Entry and of type Geographical Position. Which is a bit of a messy kind 
of thing. In particular since the id property of this thing is 
functional you would have a completely different Geo/Entry depending on 
what the id was. This is clearly very different from what we take the 
geo:x and geo:y properties to be referring to.

---

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

>   <seismo:magnitude>7</seismo:magnitude>

That's a versioning problem. While I haven't found basic RDF to be 
useful for that, I could imagine finding an 60% solution with something 
like OWL. XML is of no help here. The usual answer is to use a version 
control system to record state in time series or allow update semantics 
to your persisted representations if you don't care about past state.

Incidentally I do believe that being able to track state or trends in a 
time series fashion has commercial value in the syndication market.

cheers
Bill

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 8 Jan 2005 13:48:47 -0800

> RDF/XML's all you have is syntax featuring containment.

No, you were clear, it was just that your statement is false.
Element containment is a semantic that almost all XML data formats obey.
In fact, the only one I know of that doesn't is RDF/XML.  No other
format needs to assign those semantics to XML.

> structures, the containment must somehow be violated. RDF is a graph.

And Atom feed is a tree.  If we try to express tree structures with a
graph language, we create complexity that would not exist with a tree
language because a tree already has constraints built-in.  The extra
constraints that RDF needs in order to dig itself out of its own hole
are not necessary for languages that avoid the hole in the first place.

>> I do hope that folks understand that the relationship should be
>> obvious to anyone who does not

On the contrary, we can safely ignore languages that are perverse
in their use of XML because those languages will have to define
their own islands of semantics which are self-contained and
irrelevant to their surroundings.  Other languages do not have
to understand the non-containment semantics of rdf:Description
because those semantics are defined by RDF/XML regardless of
what other language it may be embedded within.

....Roy

---

From: Danny Ayers <[email-masked]>
Date: Sat, 8 Jan 2005 23:14:11 +0100

> what other language it may be embedded within.

Earlier you said:
[[
While I don't see any reason not to make XML's mark-up relations
explicit in the specification, I do hope that folks understand that
the relationship should be obvious to anyone who does not work in a
language that is as perversely non-mark-up as RDF/XML.
]]

While I disagree with some of the other points you have made (probably
none of the facts, more the general focus), I believe the first part
of this sentence is the issue that most directly affects Atom, and on
that I agree.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Antone Roundy <[email-masked]>
Date: Sat, 8 Jan 2005 16:40:09 -0700

> this - you'd get the desired merged entry, but with two dates.

Unless we have a way to track which parts of an entry came from which 
source (which it sounds like we don't yet), I'd have to say that 
merging entries seems like a bad idea.  Perhaps a future version of 
Atom developed after methods of doing that have been refined can be 
made to take advantage of them.  Your example does clearly show the 
value of being able to merge entries, but as far as we are from being 
able to do it properly (in the general case, that is--one could 
certainly write application specific code to merge the entries in the 
example), I think we should drop it as a goal for now.  I could see 
sense in wanting to put both of these entries into a single feed as a 
means of collecting their data (in which case, the question arises, 
would that violate the "unique ID' restriction? are they both the same 
entry, and thus able to have the same ID?), but that's probably as far 
as we can go.

> every developer, for every extension.

I think we're looking at this differently--I see two DIFFERENT lines of 
code, not two EXTRA lines of code.  Either the geo extension puts x and 
y into attributes, or it puts them into child elements--the way that 
particular extension works isn't going to vary from feed to feed, and 
thus will require the same amount of code whichever way it works.  Am I 
missing something?

Antone

---

From: Antone Roundy <[email-masked]>
Date: Sat, 8 Jan 2005 18:16:25 -0700

On Saturday, January 8, 2005, at 08:00  AM, Henry Story wrote:
> assign a geo location to an entry. This will probably not be allowed 
> by the geo ontology, which will probably specify some location class 
> to be the the subject of such a relation. One may want to imagine some 
> weird monster called a Entry-geolocation, but it will have all kinds 
> of weird properties. So let us be throw that monster out of the 
> window, even though it makes xml sense: it does not make any other 
> sense at all.
>
[WARNING: What follows is a long exploration of a few issues including 
the foundations of structural choices for XML.  You may want to skim it 
or ignore it completely.]

Good explanation.  I see what you're saying.  But I'm not convinced of 
one thing: that it doesn't make sense to assign a geo location to an 
entry.  Perhaps if my mental model of what an entry is were different, 
I'd feel differently, but it makes as much sense to me for a publisher 
to want to attach a location to an entry as it does to attach a title 
to an entry, for example.

So what is an entry?  My first thought is that it is content and 
metadata about the content.  But thinking of it that way, I run into a 
little problem: is the metadata about the content, or about the entry?  
For example, is the creation date the creation date of the content or 
of the entry?  It could be both in some cases, but it's only always 
going to be the creation date of the entry.  I think we can rule out 
the idea of an entry being just content and metadata about the content. 
  But there's a third possibility, which coincides with your diagram: an 
entry is content, metadata about the content, and metadata about the 
entry itself.

So a few questions arise:

1) What metadata can be attached to the content?

2) What metadata can be attached to the entry?

3) Is there a practical way to always have metadata appear as an 
attribute on or child of the thing it describes?

To the content: if, as in your _e2, the content is an event, the 
location where the event occurred makes sense as metadata.  I don't 
think I need to explore this any further.

To the entry: the creation date of the entry makes sense as metadata in 
a very concrete way.  I think it's easy to imagine wanting to attach an 
ID to the entry, but that's a very different thing than the creation 
date--it is not an inherent property of an entry, but something we 
attach to it by choice for convenience in referring to or identifying 
the entry.  Similarly, we can assign a title to the entry, which could 
even conceivably be different from the title of the content, for 
example, "An essay about dogs" vs. "An entry that carries as its core 
content an essay about dogs."  The title of the content is more 
obviously useful metadata, but the title of the entry certainly isn't 
ruled out.  Getting back to geo location--it's easy to imagine what the 
geo location of content would be (the place where something occurred, 
the place that something is about, the place where the content was 
written, etc.)  I'll admit, I can't imagine what "the location of an 
entry" would mean.  So, on to question #3.

Looking at your example, you have the content of one entry being a 
person, and the other being an event.  Obviously, a physical person 
doesn't travel around the world through the wires wherever the entry is 
transmitted, and the event doesn't occur inside the XML.  So I suppose 
it would be more accurate to state that the content is information 
about a person or about an event--ie. it's all metadata.  In that case, 
I'm not quite sure how to even think about the question of the metadata 
appearing as a child of the content which it describes, because the 
content is only referred to, it's not actually there.  When the content 
is actually there, as in the case of inline textual content, making the 
metadata a child of the content that it describes wouldn't really work. 
  For example, if the content is the sentence "This is a pen.", you 
wouldn't want your XML to look like this...or at least I wouldn't--it 
would be too difficult to separate the content from its metadata:

<content>
	This is a pen.
	<description>The first English sentence taught to Japanese 
students.</description>
</content>

So we end up violating the pure tree structure ideal in one way or 
another:
A) (metadata describing its sibling):
<content>This is a pen</content>
<description>The first English sentence taught to Japanese 
students.</description>

B) or (...metadata describing its sibling? or just encapsulation of the 
actual content for parsing convenience):
<content>
	<theactualcontent>This is a pen.</theactualcontent>
	<description>The first English sentence taught to Japanese 
students.</description>
</content>

C) or (fabricating a method of referring to the content that actually 
lives elsewhere--possibly in an XML document as in the first example, 
possibly not, as in the second):
<content about="foo">
	<description>The first English sentence taught to Japanese 
students.</description>
<content>
<thing id="foo">This is a pen.</thing>

<content about="Antone">
	<description>The guy typing this email.</description>
</content>

I think A and C make the most sense, which is probably why those are 
the ways most of us have settled on.  While A probably makes less sense 
than C from a purely technical point of view, it's intuitively easy to 
understand, and is the least verbose, so I for one prefer that syntax.  
However, it leads to a situation where it's not explicitly clear 
whether metadata describes its sibling or its parent.  As long as 
things are not allowed to get too convoluted--ie., children of <entry> 
can ONLY be metadata about <entry> or <content>, not about any of the 
other children of <entry>, then things don't get unmanageable.

Anyway, coming full circle to assigning a geo location to an entry...I 
guess technically, the geo location is probably really the location of 
the content.  But it makes sense to me to have it appear as a child of 
<entry>.  And I generally don't feel the need to differentiate between 
the location of the content and the location of the entry, because, the 
content being the central data of the entry, I rarely feel the need to 
think of them as different things--my mental model sort of mushes 
entries and their content together.

Whew.  I feel better now.  Sorry if you read that and didn't get 
anything out of it.

Antone