Re: PaceClarifyAuthorContributor posted
On 5/23/05, Graham [EMAIL PROTECTED] wrote: Add: o Within the atom:author and atom:contributor elements an atom:entry contains, any single Person SHOULD NOT be mentioned more than once. == Impacts == Listing several people in a single atom:author element and then crediting them individually as atom:contributors is consciously barred by this pace, in anticipation that a separate byline element may be introduced if the functionality is required. -1 to this part. Why would you bar it? There is no right answer, so just let it be looser. -1 to atom:byline, should anyone propose it. Robert Sayre
Re: PaceClarifyAuthorContributor posted
On 23 May 2005, at 12:15 pm, Robert Sayre wrote: -1 to this part. Why would you bar it? There is no right answer, so just let it be looser. Because we have to have this line: Within the atom:author and atom:contributor elements an atom:entry contains, any single Person SHOULD NOT be mentioned more than once. Anything looser makes it very hard to interpret the intended meaning of a set of atom:author and atom:contributor elements programmatically. Please describe a suitable algorithm if you wish to remove this constraint. Graham
Re: PaceClarifyAuthorContributor posted
On 5/23/05, Graham [EMAIL PROTECTED] wrote: On 23 May 2005, at 12:15 pm, Robert Sayre wrote: -1 to this part. Why would you bar it? There is no right answer, so just let it be looser. Because we have to have this line: Within the atom:author and atom:contributor elements an atom:entry contains, any single Person SHOULD NOT be mentioned more than once. That's what I'm -1 on. Anything looser makes it very hard to interpret the intended meaning of a set of atom:author and atom:contributor elements programmatically. What is the interop problem you are trying to avoid? You don't just throw in a SHOULD NOT and say otherwise it would be hard. Please describe a suitable algorithm if you wish to remove this constraint. You get N authors and N contributors. The Person rule is terrible overspecification. Robert Sayre
Re: PaceClarifyAuthorContributor posted
On 23 May 2005, at 12:28 pm, Robert Sayre wrote:
What is the interop problem you are trying to avoid? You don't just
throw in a SHOULD NOT and say otherwise it would be hard.
With the line in place, generating a basic byline is as simple as:
print by '
foreach (atom:author) print atom:author.name;
if (count(atom:contributor)) {
print with contributions from ;
foreach (atom:contributor) print atom:contributor.name;
}
Without that line, the code has to do duplicate detection (including
looking for a name in a list of names, that may be formatted
differently). It is impossible to do this with 100% reliably. Hence
the SHOULD NOT.
Graham
Re: PaceClarifyAuthorContributor posted
On 5/23/05, Graham [EMAIL PROTECTED] wrote:
On 23 May 2005, at 12:28 pm, Robert Sayre wrote:
What is the interop problem you are trying to avoid? You don't just
throw in a SHOULD NOT and say otherwise it would be hard.
With the line in place, generating a basic byline is as simple as:
print by '
foreach (atom:author) print atom:author.name;
if (count(atom:contributor)) {
print with contributions from ;
foreach (atom:contributor) print atom:contributor.name;
}
Without that line, the code has to do duplicate detection ...
Fully disagree. Try a record album by the Rolling Stones or
Grandmaster Flash and The Furious 5. OK to list the band members as
contributors? Definitely.
later,
Robert Sayre
Re: PaceClarifyAuthorContributor posted
On 23 May 2005, at 1:09 pm, Robert Sayre wrote: Fully disagree. Try a record album by the Rolling Stones or Grandmaster Flash and The Furious 5. OK to list the band members as contributors? Definitely. Maybe there's a minor bug in the wording here, but the restriction is not intended to block that (mentioning the band and then the member would not count as mentioning someone twice), and the pseudocode I proposed would produce more-or-less sensible results. In any case, the alternative you propose is no model at all, and anything created under would not be decodeable programatically, unless you can provide psuedocode that proves otherwise. Graham
Re: PaceClarifyAuthorContributor posted
* Robert Sayre [EMAIL PROTECTED] [2005-05-23 13:40]: What is the interop problem you are trying to avoid? You don't just throw in a SHOULD NOT and say otherwise it would be hard. How else would you present a list of distinct authors for a set of entries? What is the point of allowing multiple atom:author elements, if not to require that each of them refer to only a single person (or entity) so that the data can be extracted precisely without resorting to fuzzy matching? I thought wed gone over this. Regards, -- Aristotle
Re: PaceClarifyAuthorContributor posted
On 5/23/05, Graham [EMAIL PROTECTED] wrote: On 23 May 2005, at 1:09 pm, Robert Sayre wrote: Fully disagree. Try a record album by the Rolling Stones or Grandmaster Flash and The Furious 5. OK to list the band members as contributors? Definitely. Maybe there's a minor bug in the wording here, There's a large bug in the idea, IMO. In any case, the alternative you propose is no model at all, and anything created under would not be decodeable programatically, unless you can provide psuedocode that proves otherwise. Fully disagree. I reject the notion that you have generate a complete sentence. You can trivially generate a two lists of strings. Robert Sayre
Re: PaceClarifyAuthorContributor posted
* Graham [EMAIL PROTECTED] [2005-05-23 12:50]: http://www.intertwingly.net/wiki/pie/PaceClarifyAuthorContributor +1 Regards, -- Aristotle
Re: PaceClarifyAuthorContributor posted
* Robert Sayre [EMAIL PROTECTED] [2005-05-23 13:30]: -1 to atom:byline, should anyone propose it. We already have pretty good consensus that bylines, if needed by anyone, will be implemented in an extension, not in Atom. No need to punch it down here again separately. Regards, -- Aristotle
Re: PaceClarifyAuthorContributor posted
On 5/23/05, A. Pagaltzis [EMAIL PROTECTED] wrote: * Robert Sayre [EMAIL PROTECTED] [2005-05-23 13:30]: -1 to atom:byline, should anyone propose it. We already have pretty good consensus that bylines, if needed by anyone, will be implemented in an extension, not in Atom. Is your name Tim or Paul? If not, please avoid declaring what the consensus is. It only causes problems. Trust me on this. No need to punch it down here again separately. -1 to atom:byline. :) Robert Sayre
Re: PaceClarifyAuthorContributor posted
* Robert Sayre [EMAIL PROTECTED] [2005-05-23 14:45]: On 5/23/05, A. Pagaltzis [EMAIL PROTECTED] wrote: * Robert Sayre [EMAIL PROTECTED] [2005-05-23 13:30]: -1 to atom:byline, should anyone propose it. We already have pretty good consensus that bylines, if needed by anyone, will be implemented in an extension, not in Atom. Is your name Tim or Paul? If not, please avoid declaring what the consensus is. It only causes problems. Trust me on this. Sorry; it is not for me to determine whether the thus far 8 +1 votes in favour of punting any byline element to an extension constitute a consensus. In any case, the point was that it clearly doesnt look like anyone is trying to propose such a thing, so we should please stick to the points that are actually being discussed. Regards, -- Aristotle
Re: PaceClarifyAuthorContributor posted
On 5/23/05, A. Pagaltzis [EMAIL PROTECTED] wrote: In any case, the point was that it clearly doesn't look like anyone is trying to propose such a thing, so we should please stick to the points that are actually being discussed. Ah, yes, the point. That would be banning duplicate 'Persons' will obviate the need for fuzzy logic and constitute a coherent 'model' to program against. YMMV. Robert Sayre
Re: PaceClarifyAuthorContributor posted
On Mon, May 23, 2005 at 02:29:33PM +0200, A. Pagaltzis wrote: * Robert Sayre [EMAIL PROTECTED] [2005-05-23 13:40]: What is the interop problem you are trying to avoid? You don't just throw in a SHOULD NOT and say otherwise it would be hard. How else would you present a list of distinct authors for a set of entries? What is the point of allowing multiple atom:author elements, if not to require that each of them refer to only a single person (or entity) so that the data can be extracted precisely without resorting to fuzzy matching? I thought we???d gone over this. I think we're trying to do too much here. Why on earth are we disallowing a list of authors that includes the same person twice? Why does it actually cause problems? I can write the following English sentence: The book was written by James Aylett, James Aylett, and James Aylett. I can do so meaning the /same/ James Aylett, using the repetition for effect. Banning this in Atom doesn't actually seem to have any good reason beyond a kind of technical tidying. Surely it's more useful to have the semantics if you list the same person twice, you mean it (leaving mean it to be a context of the feed; the feed description could explain it, for instance). So I'm -1 on this restriction, as I don't think it actually helps anyone. If you've got a way of displaying a list of people who wrote an article, then you've got a way that will work no matter which people you put in there. If the author of an entry or feed really wants the same person multiple times, who are we to stop them? James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: PaceClarifyAuthorContributor posted
* James Aylett [EMAIL PROTECTED] [2005-05-23 15:15]: I think we're trying to do too much here. Why on earth are we disallowing a list of authors that includes the same person twice? Why does it actually cause problems? I can write the following English sentence: The book was written by James Aylett, James Aylett, and James Aylett. Sorry, I got confused because I read the Impacts section Robert quoted before reading the entire Pace in detail. This is what the Impacts section of the Pace refers to: authornameJames Aylett, James Aylett, and James Aylett/name/author +1 to forbidding this. This is what the last change directed in the Pace forbids and which the last sentence in the Rationale refers to: authornameJames Aylett/name/author authornameJames Aylett/name/author authornameJames Aylett/name/author -1 to forbidding this. In other words, I am still +1 to most of the Pace, save for the one addition to 4.1.2 which imposes this restriction. Which is actually precisely what Robert objected to once you see past the irrelevant squabble over his mention of the byline. :-) Regards, -- Aristotle
Re: PaceClarifyAuthorContributor posted
* James Aylett [EMAIL PROTECTED] [2005-05-23 14:01+0100] On Mon, May 23, 2005 at 02:29:33PM +0200, A. Pagaltzis wrote: * Robert Sayre [EMAIL PROTECTED] [2005-05-23 13:40]: What is the interop problem you are trying to avoid? You don't just throw in a SHOULD NOT and say otherwise it would be hard. How else would you present a list of distinct authors for a set of entries? What is the point of allowing multiple atom:author elements, if not to require that each of them refer to only a single person (or entity) so that the data can be extracted precisely without resorting to fuzzy matching? I thought we???d gone over this. I think we're trying to do too much here. Why on earth are we disallowing a list of authors that includes the same person twice? Why does it actually cause problems? I can write the following English sentence: The book was written by James Aylett, James Aylett, and James Aylett. I can do so meaning the /same/ James Aylett, using the repetition for effect. Banning this in Atom doesn't actually seem to have any good reason beyond a kind of technical tidying. Surely it's more useful to have the semantics if you list the same person twice, you mean it (leaving mean it to be a context of the feed; the feed description could explain it, for instance). It would be good if Atom were clear on whether repetition of the exact same name implies the two authors are distinct (eg. things written by father/son pairings, where they have same name). Dan
Re: PaceClarifyAuthorContributor posted
On 5/23/05, Dan Brickley [EMAIL PROTECTED] wrote: It would be good if Atom were clear on whether repetition of the exact same name implies the two authors are distinct (eg. things written by father/son pairings, where they have same name). Why would that be good? Robert Sayre
Re: PaceClarifyAuthorContributor posted
On Mon, May 23, 2005 at 10:35:07AM -0400, Robert Sayre wrote: It would be good if Atom were clear on whether repetition of the exact same name implies the two authors are distinct (eg. things written by father/son pairings, where they have same name). Why would that be good? I'm -1 on having the spec say anything. I'm +0.5 on the spec explicitly saying that you can't infer anything. I don't see this as something that has any actual technical impact - I think people are trying to clear up a possible ambiguity that is useful to allow. One reason why I think it's not a good idea to restrict this is that if we say repetition of the same atom:name implies distinct Person referents, we're implying that you shouldn't have the same Person referent using different names (eg: pseudonyms) - something that is impossible to detect, and so can't reasonably be part of a spec. And if we're not trying to disallow the same person being referred to by two distinct textual strings, then why are we disallowing it for two identical textual strings? Seems an arbitrary non-technical semantic to me. James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: PaceClarifyAuthorContributor posted
* Robert Sayre [EMAIL PROTECTED] [2005-05-23 10:35-0400] On 5/23/05, Dan Brickley [EMAIL PROTECTED] wrote: It would be good if Atom were clear on whether repetition of the exact same name implies the two authors are distinct (eg. things written by father/son pairings, where they have same name). Why would that be good? So we can be clear on the conclusions that can be drawn from an Atom description of a document, eg. if creating an A-Z index of authors (where two distinct John Smith entries might be needed), or merging against other information about the author(s) (eg. their photo url, lists of interests, posts/comments in other systems, etc). Dan
Re: PaceClarifyAuthorContributor posted
On Mon, May 23, 2005 at 10:42:25AM -0400, Dan Brickley wrote: It would be good if Atom were clear on whether repetition of the exact same name implies the two authors are distinct (eg. things written by father/son pairings, where they have same name). So we can be clear on the conclusions that can be drawn from an Atom description of a document, eg. if creating an A-Z index of authors (where two distinct John Smith entries might be needed), or merging against other information about the author(s) (eg. their photo url, lists of interests, posts/comments in other systems, etc). Why can't we just have the semantics that if you have two Person constructs, you'll get the effects of having two Person constructs? That way it's up to the producer of the feed - if they want the semantics that they'll have identical names listed twice in author lists, indexes or whatever, they can do that. If they'd rather not, they can do the uniqueness filtering on creation. Baking it into the spec strikes me as needlessly creating rules - we can be precise about what the semantics are without this rule, IMHO. James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: PaceClarifyAuthorContributor posted
* Dan Brickley [EMAIL PROTECTED] [2005-05-23 16:40]: It would be good if Atom were clear on whether repetition of the exact same name implies the two authors are distinct (eg. things written by father/son pairings, where they have same name). Doesnt seem to me like there should be any implication. Any user interface that presents a list of authors which contains identically named, but distinct authors will have to somehow disambiguate them in order to avoid confusing the user sooner or later. If a publisher wants to be certain of a particular interpretation he will need to make the elements distinct anyway. I was going to mention that there are two other elements in atom:author besides atom:name, but now that I think about it Im not sure if two elements with identical content in the atom:name element but divergent information in the others can automatically be thought of as referring to different authors or not. I think it is intuitive and should be implied that they are different authors, though, even if they are different only in the sense that they refer to the same physical person acting in different roles. I suppose that in this way, a meaningful, though application-specific subset of the semantics offered by allowing atom:category in these elements would be implementable. Whatever it is, I dont see a strong case for prescribing a any particular interpretation here. Regards, -- Aristotle
Re: PaceClarifyAuthorContributor posted
* James Aylett [EMAIL PROTECTED] [2005-05-23 15:43+0100] On Mon, May 23, 2005 at 10:35:07AM -0400, Robert Sayre wrote: It would be good if Atom were clear on whether repetition of the exact same name implies the two authors are distinct (eg. things written by father/son pairings, where they have same name). Why would that be good? I'm -1 on having the spec say anything. I'm +0.5 on the spec explicitly saying that you can't infer anything. I don't see this as something that has any actual technical impact - I think people are trying to clear up a possible ambiguity that is useful to allow. I'm fine with either design; was just a plea for the chosen design to be documented clearly. Note: the description of multiple authors of an entry does not in itself imply that each of these descriptions is about a different entity would be plenty. One reason why I think it's not a good idea to restrict this is that if we say repetition of the same atom:name implies distinct Person referents, we're implying that you shouldn't have the same Person referent using different names (eg: pseudonyms) - something that is impossible to detect, and so can't reasonably be part of a spec. Fair point. Again I'm not arguing that distinctness be part of the spec, just that people have a tendency to assume that distinctness is intended, so a few words to be explicit on Atom's assumptions would be worthwhile. I'm reminded of http://internetalchemy.org/2005/04/unique-name-assumption Two sons and two fathers went to a pizza restaurant. They ordered three pizzas. When they came, everyone had a whole pizza. How can that be? And if we're not trying to disallow the same person being referred to by two distinct textual strings, then why are we disallowing it for two identical textual strings? Seems an arbitrary non-technical semantic to me. I'm fine with allowing it. But there are two quite different designs here that look the same at the instance level; only the Atom spec can arbitrate between users who take differing interpretations. Dan James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: PaceClarifyAuthorContributor posted
On 23 May 2005, at 3:45 pm, James Aylett wrote: Why can't we just have the semantics that if you have two Person constructs, you'll get the effects of having two Person constructs? That way it's up to the producer of the feed - if they want the semantics that they'll have identical names listed twice in author lists, indexes or whatever, they can do that. That's the intention of the spec, and the restriction. If you can come up with better wording, then we can go with that. The other intention is that one person shouldn't (and doesn't need to be) listed as both an author and a contributor (ie a author is by definition a contributor). Does anyone object to that? Graham
Re: PaceClarifyAuthorContributor posted
On Mon, May 23, 2005 at 04:14:15PM +0100, Graham wrote: The other intention is that one person shouldn't (and doesn't need to be) listed as both an author and a contributor (ie a author is by definition a contributor). Does anyone object to that? If your intention is to disallow James Aylett as both contributor and author, I'm -0 (at least, possibly +0). If your intention is to disallow James Aylett and James Lark as authors, and James Aylett as contributor (with James Lark as a second contributor) then I'm -1. Because that's semantically the same as Funky Group Name as author, and James Aylett and James Lark as contributors, which I would find useful. James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: PaceClarifyAuthorContributor posted
On Mon, May 23, 2005 at 11:12:33AM -0400, Dan Brickley wrote: I'm fine with either design; was just a plea for the chosen design to be documented clearly. Note: the description of multiple authors of an entry does not in itself imply that each of these descriptions is about a different entity would be plenty. I'd be happy with that (particularly as the concept, but I'm happy with it textually as well). James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: PaceClarifyAuthorContributor posted
On 5/23/05, Graham [EMAIL PROTECTED] wrote: The other intention is that one person shouldn't (and doesn't need to be) listed as both an author and a contributor (ie a author is by definition a contributor). Does anyone object to that? Yes. It's a total rathole. Just state the cardinality and be done with it. Robert Sayre
Re: PaceClarifyAuthorContributor posted
On 23 May 2005, at 2:55 pm, James Aylett wrote: -- atom:author atom:personatom:nameAnne Rice/atom:name/atom:person atom:personatom:nameHoward Allen O'Brien/atom:name/ atom:person /atom:author -- then I've hacked around your restriction. That's still the same person listed twice. As I understand your wording, it's violating the spec - but it's undetectable. No way on earth any Atom processor that isn't a human being is going to notice, so how can we reasonably put that as a restriction in the spec? That's exactly why there's a restriction, because the processor can't tell for itself what's going on, so it needs the publisher to provide correct data about what's what. With the restriction, the processor can safely treat them as separate people and tell the end user This entry was written by Anne Rice and Howard Allen O'Brien. Without the restriction, all it can conclude is The names Anne Rice and Howard Allen O'Brien are in some way related to the authorship of this entry Graham
Re: PaceClarifyAuthorContributor posted
On Mon, May 23, 2005 at 04:20:44PM +0100, Graham wrote: -- atom:author atom:personatom:nameAnne Rice/atom:name/atom:person atom:personatom:nameHoward Allen O'Brien/atom:name/ atom:person /atom:author -- then I've hacked around your restriction. That's still the same person listed twice. As I understand your wording, it's violating the spec - but it's undetectable. No way on earth any Atom processor that isn't a human being is going to notice, so how can we reasonably put that as a restriction in the spec? That's exactly why there's a restriction, because the processor can't tell for itself what's going on, so it needs the publisher to provide correct data about what's what. With the restriction, the processor can safely treat them as separate people and tell the end user This entry was written by Anne Rice and Howard Allen O'Brien. Without the restriction, all it can conclude is The names Anne Rice and Howard Allen O'Brien are in some way related to the authorship of this entry Why can't you conclude that the entry was written by Anne Rice and Howard Allen O'Brien? That's what it says (well, authored). It's the responsibility of the creator of the feed to ensure it makes sense - our job with Atom isn't really to try to define the semantics of authorship, just to provide a way of expressing authorship (no matter what your semantics are). I don't see a /technical/ reason for prohibiting this. None of the examples given cause me any problems, providing (as danbri says) that the spec makes it clear that we're not imposing these restrictions. Let the publishers decide what to say (because they will anyway, even if only in 0.001% of the cases and by mistake in an undetectable way). James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: PaceClarifyAuthorContributor posted
On 5/23/05, James Aylett [EMAIL PROTECTED] wrote: I don't see a /technical/ reason for prohibiting this. None of the examples given cause me any problems, providing (as danbri says) that the spec makes it clear that we're not imposing these restrictions. Let the publishers decide what to say (because they will anyway, even if only in 0.001% of the cases and by mistake in an undetectable way). Exactly. It's extremely easy to think of cases that don't fit the model proposed. Consider the Huffington Post, where the feed might list Arianna Huffington as the author, and everybody else as a contributor. But, it would make sense to list her as a contributor as well. Robert Sayre
Re: PaceClarifyAuthorContributor posted
On May 23, 2005, at 5:18 AM, Graham wrote: On 23 May 2005, at 1:09 pm, Robert Sayre wrote: Fully disagree. Try a record album by the Rolling Stones or Grandmaster Flash and The Furious 5. OK to list the band members as contributors? Definitely. Maybe there's a minor bug in the wording here Uh, Graham, I thought your Pace did a good job of capturing the consensus that seems to be emerging, and then slipped in just a little extra with the name-duplication rules. I'm with Rob, that stuff is past the 80/20 point, I'd suggest you pare down the Pace as a friendly amendment. -Tim
Re: PaceClarifyAuthorContributor posted
On May 23, 2005, at 7:45 AM, James Aylett wrote: Baking it into the spec strikes me as needlessly creating rules - we can be precise about what the semantics are without this rule, IMHO. +1 -Tim
Re: PaceClarifyAuthorContributor posted
On 23 May 2005, at 4:58 pm, Tim Bray wrote: Uh, Graham, I thought your Pace did a good job of capturing the consensus that seems to be emerging, and then slipped in just a little extra with the name-duplication rules. I'm with Rob, that stuff is past the 80/20 point, I'd suggest you pare down the Pace as a friendly amendment. -Tim Pared down. Graham
Re: PaceClarifyAuthorContributor posted
On 23 May 2005, at 4:52 pm, Robert Sayre wrote: Exactly. It's extremely easy to think of cases that don't fit the model proposed. Consider the Huffington Post, where the feed might list Arianna Huffington as the author, and everybody else as a contributor. But, it would make sense to list her as a contributor as well. Why? She's already credited as the author. If you can explain why that isn't completely redundant and confusing to software, a gold star to you. Graham
Re: PaceClarifyAuthorContributor posted
On Monday, May 23, 2005, at 09:12 AM, Dan Brickley wrote: I'm reminded of http://internetalchemy.org/2005/04/unique-name-assumption Two sons and two fathers went to a pizza restaurant. They ordered three pizzas. When they came, everyone had a whole pizza. How can that be? Possible answers: * One of them already had a pizza when they entered the restaurant. * They stole a pizza from somebody else in the restaurant before theirs came. * The one that didn't participate in the joint ordering of three pizzas placed a separate order for one pizza, which was filled before the order for three. * When they came refers to when the came to the restaurant--they all had pizzas before they arrived, but wanted three more. BTW, +1 to the Pace
Re: PaceClarifyAuthorContributor posted
On Mon, May 23, 2005 at 05:08:10PM +0100, Graham wrote: Exactly. It's extremely easy to think of cases that don't fit the model proposed. Consider the Huffington Post, where the feed might list Arianna Huffington as the author, and everybody else as a contributor. But, it would make sense to list her as a contributor as well. Why? She's already credited as the author. If you can explain why that isn't completely redundant and confusing to software, a gold star to you. Erm ... it's not redundant, because it's expressing something that a person might want to express. Software can't really be confused by this, providing we make semantics clear - and I don't think people will be confused (unless the feed producer intended them to be confused). However I'm not religious about this particular issue, and I'm +1 on the latest PaceClarifyAuthorContributor. I think we still need a clarification along the lines of what danbri suggested, to make things as obvious as possible. James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: PaceClarifyAuthorContributor posted
On 5/23/05, Graham [EMAIL PROTECTED] wrote: On 23 May 2005, at 4:52 pm, Robert Sayre wrote: Exactly. It's extremely easy to think of cases that don't fit the model proposed. Consider the Huffington Post, where the feed might list Arianna Huffington as the author, and everybody else as a contributor. But, it would make sense to list her as a contributor as well. Why? She's already credited as the author. If you can explain why that isn't completely redundant and confusing to software, a gold star to you. Authorship is confusing to software, silly. - In section 4.2.3, append to: The atom:contributor element is a Person construct that indicates a person or other entity who contributed to the entry or feed. The text: and who is not also a named author. - -1. Robert Sayre
Re: PaceClarifyAuthorContributor posted
On Mon, May 23, 2005 at 10:36:33AM -0600, Antone Roundy wrote: I'm reminded of http://internetalchemy.org/2005/04/unique-name-assumption Two sons and two fathers went to a pizza restaurant. They ordered three pizzas. When they came, everyone had a whole pizza. How can that be? Possible answer [snip] They participated in collective ownership, had being an indication of possession, not of eating. (The question isn't terribly well phrased, because the 'and' in Two sons and two fathers strongly suggests, to me at least, that they are distinct sets.) James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: PaceClarifyAuthorContributor posted
Dan Brickley wrote: So we can be clear on the conclusions that can be drawn from an Atom description of a document, eg. if creating an A-Z index of authors You won't be able to produce such an index anyway, because atom:name is free text. Names might appear as John Smith, J. Smith and Smith, J.. Moreover, all these three cases might refer to the same John Smith, or two or three distinct John Smith (well, actually, one might also be James Smith, or Janet Smith ;-) ) I already raised up the Person identity [1] matter, I was answered it's not an Atom matter, use an extension (such as FOAF). I agree. [1] http://www.imc.org/atom-syntax/mail-archive/msg13816.html -- Thomas Broyer
