Re: Profile links
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 Bill de hÓra wrote: James M Snell wrote: 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 x:profilehttp://example.com/profiles/weblog/x:profile x:profilehttp://example.com/profiles/podcast/x:profile /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 Works for me. '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
Re: Profile links
On 10/22/05, James M Snell [EMAIL PROTECTED] 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 x:profilehttp://example.com/profiles/weblog/x:profile x:profilehttp://example.com/profiles/podcast/x:profile /entry I would prefer a [EMAIL PROTECTED]'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 Gregoriohttp://bitworking.org
Re: Profile links
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. 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. 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.
Re: Profile links
Joe Gregorio wrote: On 10/22/05, James M Snell [EMAIL PROTECTED] 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 x:profilehttp://example.com/profiles/weblog/x:profile x:profilehttp://example.com/profiles/podcast/x:profile /entry I would prefer a [EMAIL PROTECTED]'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/ I thought that head[profile='list-o-uris] was the right approach for XHTML profiles? - James
Re: Profile links
On 10/24/05, James M Snell [EMAIL PROTECTED] wrote: Joe Gregorio wrote: I would prefer a [EMAIL PROTECTED]'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/ I thought that head[profile='list-o-uris] was the right approach for XHTML profiles? 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 -- Joe Gregoriohttp://bitworking.org
Re: Profile links
At 12:45 PM 2005-10-24, Joe Gregorio wrote: On 10/24/05, James M Snell [EMAIL PROTECTED] wrote: Joe Gregorio wrote: I would prefer a [EMAIL PROTECTED]'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/ I thought that head[profile='list-o-uris] was the right approach for XHTML profiles? 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. 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
Re: Profile links
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. 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. 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
Re: Profile links
James M Snell wrote:
Bill de hÓra wrote:
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.
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.
Microformats for the most part have a defined structure; this proposal
isn't providing structure.
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.
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
Re: Profile links
Bill de hÓra wrote: Microformats for the most part have a defined structure; this proposal isn't providing structure. For the most part yes. 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. Using atom:link strikes me as tag abuse [1]. But that's what 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
Re: Profile links
James M Snell wrote: Bill de hÓra wrote: Microformats for the most part have a defined structure; this proposal isn't providing structure. For the most part yes. 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. Using atom:link strikes me as tag abuse [1]. But that's what 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. (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
Re: Profile links
Bill de hÓra wrote: (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 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:profilehttp://example.com/profiles/weblog/x:profile x:profilehttp://example.com/profiles/podcast/x:profile /entry This gets the job done. simple, easy, lightweight. - James
Re: Profile links
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 x:profilehttp://example.com/profiles/weblog/x:profile x:profilehttp://example.com/profiles/podcast/x:profile /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 Works for me.
Re: Profile links
James M Snell wrote: 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 x:profilehttp://example.com/profiles/weblog/x:profile x:profilehttp://example.com/profiles/podcast/x:profile /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 Works for me. '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
Re: Profile links
On 10/22/05, James M Snell [EMAIL PROTECTED] wrote:
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
Re: Profile links
jokingRobert: 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
Robert Sayre wrote:
On 10/22/05, James M Snell [EMAIL PROTECTED] wrote:
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
Profile links
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
Re: Profile links
James M Snell wrote:
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?
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
Re: Profile links
Bill de hÓra wrote:
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.
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
Re: Profile links
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: 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.
Re: Profile links
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
