Subject: Proposal to register rel="about"

From: "Herbert van de Sompel" <[email-masked]>
Date: Thu, 11 Sep 2008 16:42:23 -0600

hi,

The ORE effort [1] that proposes a profile of Atom to meet its requirements
[2], has a need to express that an Atom Entry provides information/metadata
about some other resource. While this need can be met through the
introduction of a rel with a value specific to the ORE effort (e.g. rel="
http://www.openarchives.org/ore/atom/about"), we came to understand that
there are other Atom use cases in which Entries are about other resources.
As such, we think it could be beneficial to register a relationship (e.g.
rel="about") to express such "about-ness" in the IANA Link Relations
registry [3].

The Atom use cases we refer to use Entries as containers to provide
"metadata" about some web resource other than the Entry itself. For example,
the GData Entry <http://gdata.youtube.com/feeds/api/videos/S_bcAOlK0io > is
about the YouTube video by the Cribs <
http://www.youtube.com/watch?v=S_bcAOlK0io>: the atom:author, atom:title,
and atom:content elements are metadata about the video. The same approach is
used in Entries published by academic publishers: the atom:author,
atom:title, etc. elements are metadata about a journal article that is
described by the Entry.

This class of Atom use cases contrasts with cases in which Atom Entries do
not describe other resources, but are just ... err ... themselves. This is
the case with most blog entries, in which e.g. atom:author is the creator of
the Entry, atom:title is a title for the Entry assigned by the creator, etc.
This metadata does pertain to the Entry itself, not to some external
resource.

We understand that an RFC that specifies the proposed rel="about"
relationship would have to express which child elements of atom:entry
pertain to the resource described by the Entry, and which to the Entry
itself, whenever a rel="about" is present in an Entry. Our current thinking
with this regard is as follows:

(a) /entry/id, /entry/published, /entry/updated, /entry/rights,
/entry/link@rel="self", /entry/link@rel="license" pertain to the Entry
(b) all other child elements of /entry that are in the Atom namespace
pertain to the resource that is the target of the "about" relationship.
(c) for Atom extension elements:
- The definition of the extension can specify whether the extension elements
pertain to the resource that is the target of the "about" relationship.
- In case no such definition is available, the extension elements pertain to
the Entry.

We would very much appreciate your feedback, both regarding the general idea
of registering an "about" relationship, and regarding the specifics of the
interpretation of child elements of atom:entry.

Cheers

Herbert Van de Sompel, Michael L. Nelson, Robert Sanderson

[1] http://www.openarchives.org/ore/toc
[2] http://www.openarchives.org/ore/documents/atom_revision_20080801.html
[3] http://www.iana.org/assignments/link-relations.html

-- 
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/

---

From: Antone Roundy <[email-masked]>
Date: Thu, 11 Sep 2008 21:45:48 -0500

Herbert van de Sompel wrote:
> "metadata" about some web resource other than the Entry itself. For 
> example, the GData Entry 
> <http://gdata.youtube.com/feeds/api/videos/S_bcAOlK0io > is about the 
> YouTube video by the Cribs <http://www.youtube.com/watch?v=S_bcAOlK0io>

My impression upon looking at the entry is that you could do this 
instead (and add an atom:summary element with textual content):

<content src="http://www.youtube.com/watch?v=S_bcAOlK0io" />

What that would do is incorporate the YouTube video as part of the 
entry.  That would seem the appropriate method if you want the entry 
metadata to talk about the external resource.

If the content of the entry is commentary about an external resource, 
then I could see having an "about" link relation to indicate that, but 
then the entry metadata would be talking about the entry, not the 
external resource.

 > itself, whenever a rel="about" is present in an Entry.

The idea of a link relation changing the meaning of a core Atom element 
doesn't sound right to me.

Antone

---

From: "Erling Wegger Linde" <[email-masked]>
Date: Fri, 12 Sep 2008 19:43:46 +0200

On Fri, Sep 12, 2008 at 4:45 AM, Antone Roundy <[email-masked]> wrote:
>> about the YouTube video by the Cribs
>> <http://www.youtube.com/watch?v=S_bcAOlK0io>
>
> My impression upon looking at the entry is that you could do this instead
> (and add an atom:summary element with textual content):
>

I have another use case which I personally think justifies registering
the rel="about" for Atom Entries, please correct me if I'm wrong about
this.

What if you use Atom entries as wrappers for other resources?

Let's say you have an issuetracker (Jira, Trac, Bugzilla etc.) which
you create/manage issues in, through a user interface. Such
issuetrackers may provide SOAP, REST etc. endpoints, but probably
nothing that outputs Atom and/or RDF (using the baetle ontology). You
want to create an AtomPub service that provides collections of
issues/bugs for instance all issues belonging to a project.

An issue has a summary, a creator (author), and other properties that
would match some of the elements of an Atom entry. (other details
could be put in the <content> element..). It would be extremely useful
for a client to know that the summary of the Atom entry is actuall the
summary property of an issue e.g. <link rel="about"
href="http://issuetracker/project1/issue1">. You could not embed the
represenation found at http://issuetracker/project1/issue1 in the
entry using <content src="http://issuetracker/project1/issue1"> as
this probably would be hard for a non-human client to parse.

Furthermore, even if it were possible to embed some sort of XML
representation of the issue, what if you would like to express it in
RDF/XML or N3? Well you could of course create a new
resource/representation e.g http://issuetrackerwrapper/projec1/issue1
and link this into your Atom entry, but I think that would be a waste
of energy and resources, compared to just use <content
type="application/rdf+xml">RDF content here..</content>. I think
rel="about" would be a powerful add-on to AtomPub and would make it
more compatible with the Semantic web.

Best regards,
- Erling

>
> What that would do is incorporate the YouTube video as part of the entry.
>  That would seem the appropriate method if you want the entry metadata to
> talk about the external resource.
>
> If the content of the entry is commentary about an external resource, then I
> could see having an "about" link relation to indicate that, but then the
> entry metadata would be talking about the entry, not the external resource.
>

---

From: "James Holderness" <[email-masked]>
Date: Fri, 12 Sep 2008 20:03:57 +0100

Erling Wegger Linde wrote:
> It would be extremely useful

Can you explain how a non-human client would find this:

<content src="xxx" />

harder to parse than this:

<link rel="about" href="xxx" />

I don't get it.

Regards
James

---

From: "Herbert van de Sompel" <[email-masked]>
Date: Fri, 12 Sep 2008 13:13:47 -0600

On Fri, Sep 12, 2008 at 11:43 AM, Erling Wegger Linde <[email-masked]>wrote:
Thanks for this. Erling.

Relating to you sem web comment, I want to add that one of the reasons we
are interested in rel="about" is to allow unambiguous GRDDL-ing RDF
statements from an Atom Entry. As far as we can tell, without rel="about",
it is very hard to understand in a general way what the subject of triples
extracted from Entries is.

Cheers

Herbert

> example,
> >> the GData Entry <http://gdata.youtube.com/feeds/api/videos/S_bcAOlK0io> is
> then I

---

From: Antone Roundy <[email-masked]>
Date: Fri, 12 Sep 2008 14:20:36 -0500

> What if you use Atom entries as wrappers for other resources?

It seems to me that that's exactly what <content src="..." /> is for.

> You could not embed the

Well, you could, but as you say, some clients wouldn't handle it...very 
well.  That's why, when there's no textual content in atom:content, 
atom:summary is required.

> you could of course create a new
> type="application/rdf+xml">RDF content here..</content>.

So either the content can be presented inline within the feed somehow, 
or it can be linked to somehow.  I don't see the advantage of 
link/@rel=about over content/@src=... as the linking method.

>> doesn't sound right to me.

After sending my message yesterday, I thought I probably should have 
amplified this objection more.  Allowing a link/@rel value to alter the 
meaning of core Atom elements would be dangerous, because 
implementations that don't understand the new @rel value (which they're 
not required to do, and we rejected the idea of creating any sort of 
"mustUnderstand" mechanism) would misinterpret the core Atom elements.

If you don't use content/@src to make the external resource the 
"content" of an Atom entry, but you want the entry to contain metadata 
about the external resource, then I think you need to put that metadata 
into extension elements designed for that purpose.

Antone

---

From: "Herbert van de Sompel" <[email-masked]>
Date: Fri, 12 Sep 2008 14:27:44 -0600

James,

This is not about easier parsing, but about unambiguous interpretation of
what the atom metadata elements pertain to:

(*) <content src="xxx" /> is widely used, but there is no spec out there
that tells us to make the following interpretation:

if <content src="xxx" /> is used then the atom metadata elements pertain to
xxx instead of to the Atom Entry (entry/id).

As a matter of fact, when looking at existing Atom use of src="xxx" there
are cases in which the atom metadata pertains to xxx and there are cases in
which it pertains to the Atom Entry (/entry/id).

(*) <link rel="about" href="yyy" /> would allow for unambiguous
interpretation through the introduction of a link to explicitly states what
the atom metadata is about.

I hope this helps clarifying our perspective.

Cheers

Herbert

---

From: "Erling Wegger Linde" <[email-masked]>
Date: Sat, 13 Sep 2008 10:40:16 +0200

> <link rel="about" href="xxx" />

If the representation of an issue is (X)HTML with Javascript, CSS ++ I
think you must agree that it would be hard for a non-human client to
make sense of it? My point is that you cannot always use the existing
representation of the resource you are referring to if you want a
machine-client to understand/make sense of it. Sometimes you might
want to provide an XML, or even better, RDF representation (wrapping)
of that original resource (for instance an issue in an issuetracker).
If you have to create yet another resource (e.g.
http://rdfwrapper/project1/issues1) and then use <content
src=http://rdfwrapper.."> to link it in, I think that would be an
unneccessary, complexing (is that a word?) step which would make
AtomPub harder to use for many scenarios.

If you could use <link rel="about" href="htmlrepresentationofissue">
together with for instance <content type="application/rdf+xml">RDF
represenation here..</content> I think that would be a very powerful
addition to AtomPub. Without the <link rel="about"> you wouldn't know
(in a generic way) that the contents of the <content> element is
metadata about the original issue/resource. Even harder would it be to
understand that the <summary type="text/plain">Issue summary</summar>
element of the Atom entry would be metadata about the issue.

Best regards,
Erling

---

From: Antone Roundy <[email-masked]>
Date: Sat, 13 Sep 2008 11:58:43 -0500

Erling Wegger Linde wrote:
> represenation here..</content>

I think that's what link/@rel="alternative" is for.

 >>>>> the GData Entry 
<http://gdata.youtube.com/feeds/api/videos/S_bcAOlK0io >
...
 >>>> My impression upon looking at the entry is that you could do this 
instead
 >>>> <content src="http://www.youtube.com/watch?v=S_bcAOlK0io" />
...
 > No, I don't agree. What if you haven't got a proper "wrapper resource"
 > to refer to, how could you use <content src=".."> then? You couldn't
 > do that without creating a new resource right? And what if for
 > instance you want to let a client understand that the <summary>
 > element of an Atom entry is actually metadata about another resource?

Once again, I think this is exactly what <content src="..." /> is for. 
For an Atom entry to have its own content that ISN'T simply an 
alternative representation of an external resource, and have 
entry/summary be a summary of anything other than entry/content is a 
corruption of Atom.

I'm not sure what you mean by "wrapper resource" -- if you have an 
external resource which is what the entry metadata is about, then that 
external resource is the "content" of the entry.  If the entry contains 
additional content commenting on the external resource, then the entry's 
metadata should be about that additional content (and in THAT case, 
rel="about" might be an appropriate way to link to the external 
resource, but the entry metadata is still about the entry content).

If the external resource is the content of the entry and you point to it 
with content/@src, then the summary is metadata about the external 
resource -- atom:summary is a summary of atom:content, whether the 
content is included inline or not.

 >> Allowing a link/@rel value to alter the
implementations
 >> that don't understand the new @rel value (which they're not required 
to do,
 >> and we rejected the idea of creating any sort of "mustUnderstand" 
mechanism)
 >> would misinterpret the core Atom elements.
 >
 > Well, I can see your point. But from working with Semantic Web
 > technology together with AtomPub I think that adding a
 > link@rel="about" to the Atom format could make Atom(Pub) a bigger
 > player in the Semantic Web (which I hope is the future).

I understand your point, but I think doing it the way you're wanting to 
would require redefining Atom in a way that's not backwards compatible 
with the existing RFC.

 > I'm not sure if this would be such a dangerous addon to Atom as you
 > indicate. I can't see why most clients can't keep on doing business as
 > usual.

 > itself, whenever a rel="about" is present in an Entry.
...
 > pertain to the resource that is the target of the "about" relationship.

Existing implementations expect entry/author, entry/category, 
entry/content, entry/contributor, entry/link (whatever the @rel value 
is), entry/source, entry/summary, and entry/title to be metadata about 
the entry. If the existence of rel="about" changes the interpretation of 
these elements, implementations that aren't aware of rel="about" won't 
interpret them as the publisher intended.

Antone

---

From: "Peter Keane" <[email-masked]>
Date: Sat, 13 Sep 2008 19:32:27 -0500

I'd have to agree that atom:content/@src is the most appropriate place
to state what this entry is "about."  To me, the fact that
atom:link/@about breaks backwards compatibility strikes me as a
possible deal-killer. But Herbert's point that current implementations
are quite fuzzy on this point is well taken.  It strikes me as one of
those tricky spots that puts Atom's existentialist view of the world
at odds with a necessarily essentialist Semantic Web view of the
world.  There are, though, some compelling reasons for using
atom:content@src since that is exactly what the  AtomPub spec
describes for the Media Link Entry.   Were ORE to adopt this (using
atom:content@src to express what the entry is "about"), it would
simply be one more definitive precedent that this is how is "should be
done."  And in the spirit of Atom ("let's allow implementations to
establish best practices, etc."), it would be a step in the right
direction for making Atom more compatible with the Semantic Web.

--peter keane

On Sat, Sep 13, 2008 at 11:58 AM, Antone Roundy <[email-masked]> wrote:
>>>>>> the GData Entry <http://gdata.youtube.com/feeds/api/videos/S_bcAOlK0io
>>>>>> >
> ...
> Once again, I think this is exactly what <content src="..." /> is for. For
> an Atom entry to have its own content that ISN'T simply an alternative
> representation of an external resource, and have entry/summary be a summary
> of anything other than entry/content is a corruption of Atom.
>
> I'm not sure what you mean by "wrapper resource" -- if you have an external
> resource which is what the entry metadata is about, then that external
> resource is the "content" of the entry.  If the entry contains additional
> content commenting on the external resource, then the entry's metadata
> should be about that additional content (and in THAT case, rel="about" might
> be an appropriate way to link to the external resource, but the entry
> metadata is still about the entry content).
>
> with content/@src, then the summary is metadata about the external resource
> -- atom:summary is a summary of atom:content, whether the content is
> included inline or not.
>
>>> meaning of core Atom elements would be dangerous, because implementations
>>> that don't understand the new @rel value (which they're not required to
>>> do,
> would require redefining Atom in a way that's not backwards compatible with
> the existing RFC.
>
> Existing implementations expect entry/author, entry/category, entry/content,
> entry/contributor, entry/link (whatever the @rel value is), entry/source,
> entry/summary, and entry/title to be metadata about the entry. If the
> existence of rel="about" changes the interpretation of these elements,
> implementations that aren't aware of rel="about" won't interpret them as the
> publisher intended.
>
> Antone
>
>

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Sun, 14 Sep 2008 13:26:58 +0200

* Herbert van de Sompel <[email-masked]> [2008-09-12 01:00]:
> The ORE effort [1] that proposes a profile of Atom to meet its
> requirements [2], has a need to express that an Atom Entry
> provides information/metadata about some other resource.

That’s `rel="alternate"` – it states that the metadata in the
Entry applies to the linked resource.

> The Atom use cases we refer to use Entries as containers to
> provide "metadata" about some web resource other than the Entry
> itself. For example, the GData Entry
> <http://gdata.youtube.com/feeds/api/videos/S_bcAOlK0io > is
> http://www.youtube.com/watch?v=S_bcAOlK0io>: the atom:author,
> atom:title, and atom:content elements are metadata about the
> video. The same approach is used in Entries published by
> academic publishers: the atom:author, atom:title, etc. elements
> are metadata about a journal article that is described by the
> Entry.

An Entry can have more than one alternate representation.

> This class of Atom use cases contrasts with cases in which Atom
> Entries do not describe other resources, but are just ... err
> ... themselves. This is the case with most blog entries, in
> which e.g. atom:author is the creator of the Entry, atom:title
> is a title for the Entry assigned by the creator, etc. This
> metadata does pertain to the Entry itself, not to some external
> resource.

If you really need to provide metadata about the metadata, rather
than metadata about the actual resource, wrap an Entry in an
Entry. (Yes, `<content type="application/atom+xml;type=entry">`.)

That isn’t the case you have outlined in the rest of your entry
however.

> This class of Atom use cases contrasts with cases in which Atom
> Entries do not describe other resources, but are just ... err
> ... themselves. This is the case with most blog entries, in
> which e.g. atom:author is the creator of the Entry, atom:title
> is a title for the Entry assigned by the creator, etc. This
> metadata does pertain to the Entry itself, not to some external
> resource.

External or not is a red herring. Either the metadata describes
that other resource, in which case the Entry is an alternate
representation, or it doesn’t, and it’s not, so the other
resource is merely related.

You can’t use Atom elements in a single Entry to provide metadata
about different resources anyway. To achieve that you would need
extension elements, not a new link relation, otherwise documents
you claim are Atom will actually be something very similar to
Atom but not Atom, since 100% RFC 4287-compliant implementations
will process such documents in an unintended manner.

> We would very much appreciate your feedback, both regarding the
> general idea of registering an "about" relationship, and
> regarding the specifics of the interpretation of child elements
> of atom:entry.

I think it’s unnecessary. Atom as specified can already express
the relationships you want.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: "Erling Wegger Linde" <[email-masked]>
Date: Sun, 14 Sep 2008 20:52:55 +0200

On Sun, Sep 14, 2008 at 1:26 PM, Aristotle Pagaltzis <[email-masked]> wrote:
> That's `rel="alternate"` – it states that the metadata in the

This is interesting. You are saying that rel="alternate" has the same
semantics as the proposed rel="about". That is, the atom:summary,
atom:author etc. applies to the resource referred to with an
atom:alternate link? E.g. if I say,

<atom:entry>
  <atom:summary type="text">A major bug...</summary>
  <atom:link rel="alternate" href="http://project1/issue1 />
</atom:entry>

The correct interpretation made by a client is that the summary "A
major bug.." is a property (summary) of the issue (which alternate
(for instance html) representation can be found at
http://project1/issue1). If this is so, I think I agree that we don't
need rel="about". But then again I don't understand why there was so
many people that reacted so strongly against Herberts proposition.
Looking forward to the follow up on this one =)

- Erling

> That isn't the case you have outlined in the rest of your entry
> however.
>
> representation, or it doesn't, and it's not, so the other
> You can't use Atom elements in a single Entry to provide metadata
> I think it's unnecessary. Atom as specified can already express

-- 
Med vennlig hilsen
Erling Wegger Linde

---

From: Eric Scheid <[email-masked]>
Date: Mon, 15 Sep 2008 11:20:59 +1000

On 15/9/08 4:52 AM, "Erling Wegger Linde" <[email-masked]> wrote:

> semantics as the proposed rel="about".

If this is so, then what @rel would I use for the following use case:

    I've just published the program schedule for a conference I'm
organising, and wrote a news item to announce the fact. There are thus two
resources in play

    1) http://www.oz-ia.org/2008/schedule.shtml
    2) http://www.oz-ia.org/2008/news.shtml#news-15

In the atom feed I link to (2) with @rel="alternate", and to (1) via an
inline <a/> link in the <summary type="html"/>. I would like to make an
explicit link from the news entry to the resource which is the subject of
the news entry, something more explicit than @rel="related" (which I would
use to link to other related resources, such as the list of sessions or the
registration form).

The following makes sense to me, intuitively...

    <entry>
        <id>tag:www.oz-ia.org,2008:/2008/news/15</id>
        <title>Program Schedule is online</title>
        <link rel="alternate" type="text/html"
            href="http://www.oz-ia.org/2008/news.shtml#news-15" />

        <link rel="about" type="text/html"
            href="http://www.oz-ia.org/2008/schedule.shtml" />

        <link rel="related" type="text/html"
            href="http://www.oz-ia.org/2008/program.shtml" />
        <link rel="related" type="text/html"
            href="http://www.oz-ia.org/2008/register.shtml" />

        <!-- ... -->
    </entry>

(Apologies in advance if I'm usurping the sense of @rel='about' and
derailing this thread)

e.

---

From: "Brian Smith" <[email-masked]>
Date: Thu, 18 Sep 2008 11:17:43 -0500

Aristotle Pagaltzis wrote:
> > requirements [2], has a need to express that an Atom Entry provides 
> > information/metadata about some other resource.
> 

Perhaps in theory, but not in practice. The metadata for an entry always
describes the entry that contains it. The resource being linked by
rel=alternate is supposed to encode the same information that the Atom entry
does, just in a different format or a different language. If that is the
case, then the metadata that describes the entry should also describe the
alternate representations because all the representations should encode the
same information. However, in reality, the alternate representation often
encodes similar *but slightly different* information than what is encoded in
the Atom entry. For example, a weblog entry might have the title "More
Kitten Pictures" but the alternate HTML representation might have the title
"~~~LOL~~~ More Kitten Pictures - Billy's Cute Kitty Cat Picture Photostream
by Billy Bob Barker ~~~LOL~~~".

> You can’t use Atom elements in a single Entry to provide 
> metadata about different resources anyway. To achieve that 
> you would need extension elements, not a new link relation, 
> otherwise documents you claim are Atom will actually be 
> something very similar to Atom but not Atom, since 100% RFC 
> 4287-compliant implementations will process such documents in 
> an unintended manner.

Exactly. If you want an atom entry to contain metadata for a resource other
than the entry itself, you need to put that other resource's metadata in
atom:content and not directly in the atom:entry.  For example, if you have
RDF metadata that describes some other resource, then you can easily do that
with:
    <content type='application/rdf+xml'>
         <!--metadata for the other resource-->
    </content>.

Remember that the metadata nested directly in the atom:entry element always
describes the entry itself. The rel='about' proposal would require
applications that understand rel='about' to process the entry's metadata
differently from all existing (and future) applications that don't
understand rel='about'. That would just be a mess.

- Brian

---

From: "Brian Smith" <[email-masked]>
Date: Thu, 18 Sep 2008 11:28:41 -0500

Herbert van de Sompel wrote:
> if <content src="xxx" /> is used then the
> atom metadata elements pertain to xxx
> instead of to the Atom Entry (entry/id).
	
> As a matter of fact, when looking at
> existing Atom use of src="xxx" there are
> cases in which the atom metadata pertains
> to xxx and there are cases in which it
> pertains to the Atom Entry (/entry/id).

In Atom the metadata always pertains to the entry it is contained in and not
anything else. Atom:title always is the title of the entry that contains it.
The difference between inline and out-of-line content is purely syntactic;
except for XML documents that have a DOCTYPE, you can encode the same entry
with inline or out-of-line content and the meaning doesn't change.

I do agree that there are some counter-intuitive situations. For example, if
the content/@src links to a PDF document, then the PDF document will often
have its own metadata (especially the title, authorship, and modification
time) encoded in it. Most applications want to think of the atom:title  as
being the title of the PDF document. But, that isn't the case; the
atom:title is always the title of the entry whose content is the PDF file.
There is no fixed relationship between the metadata for the entry and the
metadata for the entry's content.

Here is an example where we avoid using out-of-line content; notice that the
entry and its content have different titles, because atom:entry/atom:title
describes the entry's title, not the entry's content's title:

   <entry ...>
   <title>Title of the Entry</title>
   <content type='application/xhtml+xml'>
      <html:html ...>
         <html:head><html:title>Title of the HTML
document</html:title></html:head>
         ...
      </html>
   </content>
   </entry>

- Brian

---

From: "Peter Keane" <[email-masked]>
Date: Thu, 18 Sep 2008 12:36:48 -0500

What about the case of a Media Link Enty?

This from AtomPub spec 9.6:

"The Media Link Entry contains the metadata and IRI of the (perhaps
non-textual) Media Resource. The Media Link Entry thus makes the
metadata about the Media Resource separately available for retrieval
and alteration."

Isn't this a specified case in which the atom elements are describing
the media resource and not the entry?

I've struggled a bit in my own implementation with this exact issue,
and wishing there was a switch that could be flipped to say "this is
an MLE".  I am not sure that in practice it matters all that much,
since a specific use case will clearly suggest which you are talking
about.  I believe the challenge that Herbert is pointing to is that we
need to be more precise is we are going to be deriving RDF from the
Atom entry.

--peter keane

---

From: "Brian Smith" <[email-masked]>
Date: Thu, 18 Sep 2008 14:03:01 -0500

Peter Keane wrote:
> non-textual) Media Resource. The Media Link Entry thus makes 
> the metadata about the Media Resource separately available 
> for retrieval and alteration."
> 
> Isn't this a specified case in which the atom elements are 
> describing the media resource and not the entry?

Either the relationships between the metadata, the content, and the entry is
ambiguous and application-dependent or the metadata has to describe the
entry. Those words from the AtomPub specification imply that the
relationships are ambiguous and so AtomPub has to clarify them for its
specific use of Atom. Following that, when you have an AtomPub MLE the
metadata describes the content, when you have inline content in an AtomPub
document the relationships are ambiguous, and when you are not using AtomPub
the relationships are ambiguous even with out-of-line content. That is, you
have basically the same problems as rel='about', but without the
explicitness of the rel='about' proposal (since you cannot easily tell
whether an entry is a media link entry or not in general).

I don't think that is a very useful approach because it means we have to
write extra specification text to clarify what metadata applies to what
under what circumstances, we have to write code for each special case, and
we have to write more tests to verify that we handle all the specific
scenarios correctly. The conclusion is that Atom's metadata is meaningless
without additional application-specific clarification, so we cannot write
tools that interpret metadata uniformly across applications. That is
completely at odds with the goals of Atom. 

Instead, I prefer to think of AtomPub as a way of managing Atom entries
instead of a way of handling entries, media resources, and the media
metadata encoded as entries. Some of the entries might have out-of-line
content, and the protocol knows how to edit it, but the media resources are
always secondary to the entries. Thinking this way, there isn't a need to
have MLEs as a separate concept. Instead of regular entries vs. MLEs, we
have entries, some of which have "out-of-line content" while others have
inline content. This emphasizes that entries are all managed the same way,
that we should interpret entries' metadata uniformly, and that the entry is
the primary concept while the media resource is the secondary concept. This
fits with the way we manage media entries. An entry can exist without having
a media resource but a media resource cannot exist without a MLE. A media
resource is deleted when its MLE is deleted; the MLE isn't deleted when its
media resource is deleted (at least, that isn't required by the spec.).  We
update app:edited whenever the entry changes; because the content is part of
the entry, whenever we update the content we have to update app:edited,
regardless of whether the content is inline or out-of-line. 

Examples 1:

    <entry ...>
      <author><name>Brian</name></author>
      <content src='something.html'/>
      ...
    </entry>

Who is the author of the entry? Who is the author of something.html? Using
my way of thinking, Brian is the author of the entry and the author of the
content is unknown. Otherwise, everything is ambiguous; if the entry is part
of an AtomPub collection and the entry is a MLE then Brian is the author of
something.html and the author of the entry is unknown. But, if the entry
isn't a MLE entry then the authorship information is totally ambiguous.

Example 2:

    <entry ...>
      <id>urn:example:1</id>
      <title>My brother's puppy</title>
      <content src='http://example.org/puppy.jpg'/>
      <app:edited>2008-01-01:01:01:01Z</app:edited>          
      <updated>2008-01-01:01:01:01Z</updated>
      ...
    </entry>

    <entry ...>
      <id>urn:example:2</id>
      <title>My puppy</title>
      <content src='http://example.org/puppy.jpg'/>
      <app:edited>2008-01-01:01:01:01Z</app:edited>
      <updated>2008-01-01:01:01:01Z</updated>
      ...
    </entry>

What is the title of the image? What is the title of entry urn:example:1?
What is the title of entry urn:example:2? Can an image have two different
titles at the same time? Using my way of thinking, each entry has the title
given and the title of the image is unspecified. Using the other way of
thinking, you have a mess.

Bonus: Given an entry (in a feed or standalone), how can you determine if it
is an AtomPub MLE so that you know what disambiguation rules to apply when
interpreting the AtomPub text above literally.

> I've struggled a bit in my own implementation with this exact 
> issue, and wishing there was a switch that could be flipped 
> to say "this is an MLE".  I am not sure that in practice it 
> matters all that much, since a specific use case will clearly 
> suggest which you are talking about.  I believe the challenge 
> that Herbert is pointing to is that we need to be more 
> precise is we are going to be deriving RDF from the Atom entry.

That is why I eventually settled on the approach that I described in my last
few messages to this list. It is simultaneously 100% unambiguous and the
simplest thing that could possibly work.

Regards,
Brian

---

From: "Erling Wegger Linde" <[email-masked]>
Date: Sun, 21 Sep 2008 18:09:45 +0200

Seems like there is hard to gain consensus here.

Would it be a good idea to create some sort of "best practice
document" (RFC?) for how to "combine the Semantic Web with AtomPub" (I
guess the title should be the first thing to change =).

If we first could succeed in creating such a document describing the
current state-of-the-art, it would probably be easier to agree whether
or not additions like Herbert proposed, would be a) backward
compatible and/or b) add value ++

What do you think?
- Erling

-- 
Med vennlig hilsen
Erling Wegger Linde