Subject: Profile links

From: James M Snell <[email-masked]>
Date: Fri, 21 Oct 2005 12:07:56 -0700

Another subject that has come up in recent discussions is an extension 
that can be used to specify the purpose of a feed.  For example, is the 
feed an archive, is it a podcast, is it used for discovering web 
services or publishing blog content, etc.

The approach that I have in mind is to use link[rel="profile"] where the 
href points to a profile document of some sort.

For example,

  <feed>
    ...
    <entry>
      <link rel="profile" href="http://example.com/profiles/podcast" />
      <link rel="profile" href="http://example.com/profiles/weblog" />
      ...
    </entry>
  </feed>

The profile documents could be anything really, but generally describe 
the kinds of metadata and content that the entry is expected to 
contain.  For instance, the podcast profile could indicate that the 
entry should contain at least one link[rel="enclosure"]. 

Any single entry may contain multiple profile links.  It is up to the 
feed consumer to make sense of it all.  If an entry specifies 
contradictory profiles, it's up to the consumer to sort it out. 

The profile documents should be dereferenceable.

Thoughts? Gripes? Praise?

- James

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 21 Oct 2005 23:34:21 +0100

> Thoughts? Gripes? Praise?

I think you're proposing to enable a kind of Atom microformat - "if you
see profile ?x check for ?a ?b and ?c". Sorting it out on consumer
sounds flaky ('sounds', not 'is'), but this also might be very cool. I
wonder why you need a link to do this instead of foo:profile tag.

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Fri, 21 Oct 2005 16:15:42 -0700

>wonder why you need a link to do this instead of foo:profile tag.
Precisely.  Yes, sorting everything out on the client does *sound* 
flaky, but we're not introducing any new problem here.  XHTML 
microformats have the same problem. 

Regarding the use of a link versus foo:profile, I really have no 
preference one way or the other.  The profile reference should be a 
dereferencable link to a profile document that describes the profile 
but, for the most part, clients will likely only rarely ever dereference 
it (using the href more as an identifier).  Strictly speaking, 
dereferenceable profile links should probably use the atom:link element 
but there is no hard requirement that says a profile element wouldn't 
also work.

- James

---

From: "James Holderness" <[email-masked]>
Date: Sat, 22 Oct 2005 03:42:56 +0100

I'm not sure if I've understood you correctly, but if this could be used as 
a hint to the aggregator on how best to process/display the feed then I 
think it's a great idea.

For example, knowing that a feed was a collection of images (e.g. a Flickr 
feed) would enable the aggregator to automatically display the entries as an 
image thumbnail list. A feed of calendar events (using a microformat of some 
sort) could be automatically added to the user's calendar. I'm sure there 
are many other ways in which this could be useful.

My only worry is that without some kind of profile registry it would be very 
difficult for an aggregator to do anything meaningful with the data. Where 
would you find a list of all existing profiles? If there are 10 different 
profiles that all suggest more or less the same thing which one(s) should an 
aggregator support? Perhaps we could start with a predefined set of 
well-known profiles?

I really think this idea has great potential though.

Regards
James

James M Snell wrote:
> feed an archive, is it a podcast, is it used for discovering web services 
> or publishing blog content, etc.
>

---

From: James M Snell <[email-masked]>
Date: Fri, 21 Oct 2005 19:47:01 -0700

James Holderness wrote:

> I'm not sure if I've understood you correctly, but if this could be 
> used as a hint to the aggregator on how best to process/display the 
> feed then I think it's a great idea.
>
Yes, that's exactly what it's for.

> For example, knowing that a feed was a collection of images (e.g. a 
> Flickr feed) would enable the aggregator to automatically display the 
> entries as an image thumbnail list. A feed of calendar events (using a 
> microformat of some sort) could be automatically added to the user's 
> calendar. I'm sure there are many other ways in which this could be 
> useful.
>
> My only worry is that without some kind of profile registry it would 
> be very difficult for an aggregator to do anything meaningful with the 
> data. Where would you find a list of all existing profiles? If there 
> are 10 different profiles that all suggest more or less the same thing 
> which one(s) should an aggregator support? Perhaps we could start with 
> a predefined set of well-known profiles?
>
That's precisely why I want the profile references to be dereferenceable 
into some form of profile document that can describe the profile.  I 
considered a registry of profiles but wasn't sure if that was a good 
idea or not. Still stewing on it.  I definitely think the definition of 
profiles needs to be a community effort, much like the way that the 
microformats community is working collaboratively to define microformat 
profiles.

- James

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 22 Oct 2005 13:43:15 +0100

> microformats have the same problem.

Microformats for the most part have a defined structure; this proposal
isn't providing structure.

> but there is no hard requirement that says a profile element wouldn't

Using atom:link strikes me as tag abuse [1]. But that's what
microformats tend to do (use presentational markup for data).

cheers
Bill

[1] http://www.ucc.ie/sdata/faq.html#whatis

---

From: James M Snell <[email-masked]>
Date: Sat, 22 Oct 2005 07:52:08 -0700

>isn't providing structure.
For the most part yes.

>microformats tend to do (use presentational markup for data).
Agreed. So what's a better solution?  Like I said, I really have no 
preference one way or the other.

- James

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 22 Oct 2005 18:48:09 +0100

> preference one way or the other.

(taking off my markup hat)

If someone said to me you can check an entry's profile via an
atom:link/@rel='profile' I would say 'ok, that's fine' (soon followed by
'what should I do if all the other metadata isn't there?'). If it's
truly abuse the registrar can trap it and tell you to use something else.

The reason to pick a dedicated element instead is if the WG wants to set
a precedent on how the format is to be extended (we have multiple points
of extension and no guidance as to how to choose between them).
Otherwise I think atom:link will be ok.

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Sat, 22 Oct 2005 11:56:19 -0700

>Otherwise I think atom:link will be ok.
Hmm.. the more I think about this and the more we discuss it, the less I 
think I like link[rel="profile"].  While the URI of the profile 
reference should be dereferenceable, most of the time the profile value 
is going to be used as an identifier. 

<entry>
  <x:profile>http://example.com/profiles/weblog</x:profile>
  <x:profile>http://example.com/profiles/podcast</x:profile>
</entry>

This gets the job done. simple, easy, lightweight. 

- James

---

From: "James Holderness" <[email-masked]>
Date: Sat, 22 Oct 2005 20:28:51 +0100

James M Snell wrote:
> think I like link[rel="profile"].  While the URI of the profile reference 
> should be dereferenceable, most of the time the profile value is going to 
> be used as an identifier.
> <entry>

I agree about not using link, but shouldn't the URI be in an attribute 
rather than as content. Something like this:

<entry>
 <x:profile href="http://example.com/profiles/weblog"/>
 <x:profile href="http://example.com/profiles/podcast"/>
</entry>

Regards
James

---

From: James M Snell <[email-masked]>
Date: Sat, 22 Oct 2005 12:44:40 -0700

James Holderness wrote:

>
> James M Snell wrote:
>
>> Hmm.. the more I think about this and the more we discuss it, the 
>> less I think I like link[rel="profile"].  While the URI of the 
>> profile reference should be dereferenceable, most of the time the 
>> profile value is going to be used as an identifier.
>> <entry>
Works for me.

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 22 Oct 2005 20:58:49 +0100

>> <x:profile href="http://example.com/profiles/podcast"/>

'href's can traditionally be dereferenced, no big deal - the upside is
the markup structure does gives you scope to extend later.

'ref' - ?

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Sat, 22 Oct 2005 13:18:03 -0700

Ok, <x:profile ref="{uri}" /> works very well I think. 

  profileElement = element x:profile {
    attribute ref ( URI ),
    undefinedContent
  }

Now for some processing questions...

1. Can a profile element appear in an atom:feed/atom:source?  If so, 
what does it mean? I think it should with the caveat that the profile 
attribute should only impact the feed and should not reflect on the 
individual entries within that feed.

2. Can multiple profile elements be specified?  I think it should.  That 
way we can mark an entry, for instance, as being both a blog entry and a 
podcast.

3. What standard profiles should we consider?
    * Weblog (for atom:feed)..  BlogEntry (for atom:entry)
    * Wiki (for atom:feed).. WikiPage (for atom:entry)
    * Podcast
    * Archive
    * Search Results
    * what else?

    For each of the profiles, we need to specify what it means to 
conform to that profile

4. How can we foster the community development and adoption of profiles?

- James

---

From: Robert Sayre <[email-masked]>
Date: Sat, 22 Oct 2005 16:45:18 -0400

> Ok, <x:profile ref="{uri}" /> works very well I think.

ref? Can we please ditch the pseudo-RDF garbage? Leave an idea alone
for two seconds...

Robert Sayre

---

From: James M Snell <[email-masked]>
Date: Sat, 22 Oct 2005 20:04:43 -0700

<joking>Robert: Did you have to get special training to be so grumpy? Or 
does it just come naturally?</joking>

I actually meant to use href, but after reading the other note, I had 
ref stuck in my head and didn't catch my error. 

What I wanted to say was

<x:profile href="{uri}" />
profileElement = element x:profile {
  attribute href ( URI ),
  undefinedContent
}

- James

---

From: "James Holderness" <[email-masked]>
Date: Mon, 24 Oct 2005 01:45:58 +0100

James M Snell wrote:
> 1. Can a profile element appear in an atom:feed/atom:source?  If so, what 
> does it mean? I think it should with the caveat that the profile attribute 
> should only impact the feed and should not reflect on the individual 
> entries within that feed.

I can't see any particular use for atom:source myself, but I would 
definately want profile support at the feed level. As an aggregator I want 
to be able to display a custom view for a particular feed based on what it 
contains (e.g. slideshow view if it's a flickr feed - all images). It would 
be difficult to do something like that with only entry level profiles.

In fact, most of the profiles that are of interest to me are feed based (see 
question 3 below). I hope we're still talking about the same thing here and 
I haven't completely misinterpreted what you're proposing.

> way we can mark an entry, for instance, as being both a blog entry and a 

I'm not sure about this but when in doubt I think it'd be best leaving the 
option open (i.e. allow multiple).

> 3. What standard profiles should we consider?

Some of the ones I'd be interested in:

* Image feed (flickr.com)
* Calendar feed (eventful.com)
* Top N list
* Wish list

>    For each of the profiles, we need to specify what it means to conform 
> to that profile

I'm not sure how much of this we should be trying to do ourselves. See 
question 4.

> 4. How can we foster the community development and adoption of profiles?

For many of these profiles you could probably come up with one or two sites 
which are obvious leaders in the field (for example flickr.com for image 
feeds). If you can introduce them to the concept of a profile, but let them 
decide on what is required to conform to that profile, you're probably a 
whole lot more likely to get their support.

Regards
James

---

From: Joe Gregorio <[email-masked]>
Date: Mon, 24 Oct 2005 09:43:39 -0400

>   <x:profile>http://example.com/profiles/podcast</x:profile>

I would prefer a link@rel='profile' as it provides a nice symmetry
with (X)HTML, in particular the microformat use of such
link elements to point at XMDP documents[1].

   -joe

[1] http://www.gmpg.org/xmdp/

--
Joe Gregorio        http://bitworking.org

---

From: Antone Roundy <[email-masked]>
Date: Mon, 24 Oct 2005 09:53:23 -0600

On Oct 23, 2005, at 6:45 PM, James Holderness wrote:
> James M Snell wrote:
>> 1. Can a profile element appear in an atom:feed/atom:source?  If  
>> so, what does it mean? I think it should with the caveat that the  
>> profile attribute should only impact the feed and should not  
>> reflect on the individual entries within that feed.
>
> definately want profile support at the feed level. As an aggregator  
> I want to be able to display a custom view for a particular feed  
> based on what it contains (e.g. slideshow view if it's a flickr  
> feed - all images). It would be difficult to do something like that  
> with only entry level profiles.
>
I don't think it's possible to allow something at the feed level, but  
disallow it in atom:source (the Atom format spec could have done  
that, but I don't think an extension can add such restrictions).

What does it mean in atom:source?  That the feed that the entry came  
from conformed to the profile.

What will consuming applications do with profile elements in  
atom:source?  That's entirely up to the application developer.  Maybe  
nothing--maybe they'll ignore profiles that don't apply to the entire  
feed.  Or maybe they'll come up with something useful.

---

From: James M Snell <[email-masked]>
Date: Mon, 24 Oct 2005 09:39:35 -0700

>[1] http://www.gmpg.org/xmdp/
I thought that head[profile='list-o-uris"] was the right approach for 
XHTML profiles? 

- James

---

From: Joe Gregorio <[email-masked]>
Date: Mon, 24 Oct 2005 12:45:51 -0400

> I thought that head[profile='list-o-uris"] was the right approach for

Ok, that will teach me to whip out a quick response :)
You are correct that it is head[profile='list-o-uris"] and not a
link element as my poorly worded message would imply.
What I was trying to stress was the pointing at XMDP documents,
not so much the link element.

   -joe

---

From: Paul Denning <[email-masked]>
Date: Mon, 24 Oct 2005 15:08:24 -0400

>not so much the link element.

Or GRDDL [2].

[2]  http://www.w3.org/2003/g/data-view

If you use del.icio.us, let me suggest the use of the tag 
"atomprofile" to bookmark links to profile descriptions.
You then have a makeshift registry at [3].

[3]  http://del.icio.us/tag/atomprofile

Paul

---

From: James M Snell <[email-masked]>
Date: Sat, 29 Oct 2005 14:17:47 -0700

Ok, so I walked away from this for a few days then thought about it 
again.  Practically speaking, I don't really give a damn whether or not 
it's a <x:profile /> or a <link rel="profile" /> because folks who want 
to do this type of thing will adapt to whatever the mechanism is.  The 
profile thing is a) and identifier and b) an reference to a document 
that defines the profile.  There can be many different ways a profile 
can be defined so having a media type makes sense.  There could be 
several different profiles defined so to help differentiate, a title or 
label would be helpful.  I had said before that "while the URI of the 
profile reference should be dereferenceable, most of the time the 
profile value is going to be used as an identifier" and used that as a 
justification for not using link. Then I looked over at my 
link[rel="license"] extension and realized that the exact same argument 
applies there also.  Given this, even tho <x:profile /> would work just 
fine, I think it's best just to stick to the original <link 
rel="profile" /> idea.  It's a link to a profile; let's call it for what 
it is.

  <link rel="profile" type="some/media-type" 
href="http://example.com/some-kind-of-profile" />

- James