Re: Top 10 and other lists should be entries, not feeds.
Peter Saint-Andre wrote: Walter Underwood wrote: --On August 30, 2005 1:49:57 AM -0400 Bob Wyman [EMAIL PROTECTED] wrote: I’m sorry, but I can’t go on without complaining. Microsoft has proposed extensions which turn RSS V2.0 feeds into lists and we’ve got folk who are proposing much the same for Atom (i.e. stateful, incremental or partitioned feeds)… I think they are wrong. Feeds aren’t lists and Lists aren’t feeds. The Atom spec says: This specification assigns no significance to the order of atom:entry elements within the feed. One could read that to mean that feeds are fundamentally unordered or that Atom doesn't say what the order means. Is not logical order, if any, determined by the datetime of the published (or updated) element? Often it makes sense for the order to come from properties of the things described by the items/entries, rather than publication dates. Examples: movie listings, job listings, photos by image creation rather than upload time, etc. Generally, feeds that aren't blog content but are views into some database, ie. the same kinds of feed that are most likely to use data-centric markup extensions. Atom allows such orderings to be exposed, without requiring that a machine-friendly justification be given. Seems about right to me. cheers, Dan
Re: The Atomic age
Henry Story wrote: Is the mixed format case really possible? Last time I looked there were problems, such as different tags using attributes with the same name but with different semantics. I thought we were close last time I looked, but not quite there. It seems feasible for a somewhat constrained subset, on first investigation. Dan
Re: The Atomic age
Bjoern Hoehrmann wrote: * Dan Brickley wrote: http://www.w3.org/2001/sw/BestPractices/HTML/samples/atom/a1.xml `Content-Type: text/xml; qs=0.9`. Hurray... I could fix that... question is, to what? :) The Atom spec says Atom docs are identified using the Atom media type, but I don't see anything like a 'SHOULD NOT' regarding serving them with other types. In the mixed-format case of an instance being both valid RDF, and valid Atom, we get into pragmatics. RDF tools wouldn't know it was RDF/XML since Atom doesn't allow a toplevel rdf:RDF wrapper element as foreign markup. But Atom tools also have a claim on the content type. Maybe it could be content-negotiable? Something for everybody...? Dan
Re: The Atomic age
Sjoerd Visscher wrote: Dan Brickley wrote: Let me emphasise that I'm not claiming these Atom docs are reasonably interpreted as RDF. Just that they seem to, by happy coincidence as it were, at least share a syntax with RDF. The intepretation of this syntactic state of affairs is up for discussion. I've never understood what makes hybrid RDF/other xml formats appealing. A simple xslt conversion turnes the xml format (the whole format, not a subset) in much better RDF, with no compromises. It might well be that the XSLT/GRDDL approach is best. It depends what you're using Atom for. Lots of Atom constructs use an abc def=...ghi/abc idiom, which won't parse as RDF. For more data-oriented feeds (non-blog stuff, eg. job listings, ecommerce, events, maps etc) much more of the payload will live in extensions anyhow, and using minimal Atom (per my example) might mean the hybrid style finds a niche. For the XSLT/GRDDL case, we'd still need to agree quite which triples to generate, eg. whether to use the same namespace as 'normal' Atom, so there are some details to work out. cheers, Dan
Re: Author and contributor
* Eric Scheid [EMAIL PROTECTED] [2005-05-23 15:48+1000] On 23/5/05 3:22 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: Antone Roundy suggests: +1 make atom:author plural +1 keep atom:contributor punt bylines to an extension To me that sounds like the simplest thing that can possibly work, and looks like it hits the 80/20 mark. It also requires the least squabbling over its implementation. And Robert has expressed that he is fine with the proposal in that thread. Again, +1 to Antone¹s suggestion. +1,+1, and +1 from me too. +1, +1, +.5 from me BTW, and aside re Dublin Core semantics, DC allows all DC terms to be repeated, including 'creator'; the definition is given in http://dublincore.org/documents/dcmi-terms/ An entity primarily responsible for making the content of the resource. with the notes Examples of a Creator include a person, an organisation, or a service. Typically, the name of a Creator should be used to indicate the entity.. It says 'an entity' rather than 'the entity'. 'Primarily' might suggest one rather than many, but the notion of multiple entities being 'jointly first' in their responsibility for making the content seems to sneak us out of that one. Dublin Core has a group on Agents, see http://dublincore.org/groups/agents/ ...at the last Dublin Core Advisory Board meeting I said I'd try to get FOAF measured up against their functional requirements doc, http://rdfweb.org/pipermail/rdfweb-dev/2004-October/013820.html ...probably time to revisit that discussion. Also worth noting in that regard is that there are different idioms for deploying dc:creator (sometimes as a relationship to a string, sometimes as a relationship to an Agent of some kind) in RDF; http://danbri.org/words/?p=63 was an experiment in making explicit rules for mapping between them. Dan I¹ve expressed an affinity for the idea of putting atom:category in atom:contributor, but I see a lot of potential delay in that and no pressing need for it. seeing as that proposal was my idea, and despite no technical objections to it, I'm happy to withdraw it just so atom:author can get through the process hoops. e.
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
* 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
* 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: posted PaceAuthorContributor
* Walter Underwood [EMAIL PROTECTED] [2005-05-23 11:16-0700] --On May 23, 2005 10:52:47 AM -0700 Tim Bray [EMAIL PROTECTED] wrote: If you're worried, one good way to address the issue would be to say that the semantics of this element are based on the Dublin Core's [dc:creator], DC is pretty clear as I recall. I've been thinking that would be a good idea anyhow. Let's call it atom:creator, then, and actually use the DC definition. +1 Not because DC is better, but because it makes the metadata crosswalks (interoperability) work smoothly. FWI the original DC had Author: The person(s) primarily responsible for the intellectual content of the object (see http://dublincore.org/workshops/dc1/report.shtml first workshop report). After the 3rd workshop (on DC and images, in 1996) this became http://www.dlib.org/dlib/january97/oclc/01weibel.html#table AUTHOR OR CREATOR The person(s) or organization(s) primarily responsible for the intellectual content of the resource. What we have today is http://dublincore.org/documents/dcmi-terms/#H2 An entity primarily responsible for making the content of the resource. (Examples of a Creator include a person, an organisation, or a service. Typically, the name of a Creator should be used to indicate the entity.) Aside- the DCMI Localization and Internationalization Working Group, http://dublincore.org/groups/languages/ have been busy getting DC definitions translated into other languages. See the WG homepage for links. I realise it is just one part of Atom, but it is handy at least to have had that part of the translation effort done already. Calling it atom:creator makes sense to me; DC changed to use 'creator' rather than 'author' to accomodate digital image use cases. These also seem appealing w.r.t. Atom; there are a *lot* more digital images being shared and described now than there were back in 1996 when DC made the change. Dan
Re: posted PaceAuthorContributor
* Robert Sayre [EMAIL PROTECTED] [2005-05-23 18:26-0400] On 5/23/05, Graham [EMAIL PROTECTED] wrote: On 23 May 2005, at 7:44 pm, Dan Brickley wrote: What we have today is http://dublincore.org/documents/dcmi-terms/#H2 An entity primarily responsible for making the content of the resource. (Examples of a Creator include a person, an organisation, or a service. Typically, the name of a Creator should be used to indicate the entity.) The WG consensus in supporting multiple atom:authors seems to be against having a singular creator, so -1 on this change. Dan tells us you can have multiple dc:creators. I didn't know that, but I'd be happy to use Dublin Core if we possibly can. Yep, all the main DC terms are considered optional and repeatable. Dan
Re: How is Atom superior to RSS?
* Bob Wyman [EMAIL PROTECTED] [2005-05-22 01:52-0400] I'll be making a presentation on Tuesday which will include a slide on how Atom improves on RSS. If you have any thoughts on this subject, I would appreciate hearing them. Which version of RSS? the RDF and non-RDF strands have pretty different characteristics... The main new interesting thing for me is the protocol aspect. Re format extensibility, Atom's a step back from RSS 1.0, but a step forward from RSS 2.0. Digital signature stuff is exciting. Dan
Re: Atom feed refresh rates
* Henri Sivonen [EMAIL PROTECTED] [2005-05-05 18:35+0300] On May 5, 2005, at 16:24, Walter Underwood wrote: --On May 5, 2005 8:07:15 AM -0500 Mark Pilgrim [EMAIL PROTECTED] wrote: Not to be flippant, but we have one that's widely available. It's called the Expires header. You need the information outside of HTTP. To quote from the RSS spec for ttl: This makes it possible for RSS sources to be managed by a file-sharing network such as Gnutella. Caching information is about knowing when your client cache is stale, regardless of how you got the feed. Virtually everyone with IP connectivity can do HTTP, and HTTP has the Expires header. If this feature is important to you, why would you switch to a transfer protocol that doesn't have the feature? (I am not claiming anything about the actual Gnutella features.) To me, the what if the feed is not over HTTP argumentation seems theoretical over-generalization. +1 FWIW various P2P/filesharing protocols use HTTP, eg. Kazaa and others make use of HTTP's ability to request a byte range, handy if you're requesting chunks of the same file from different servers. Those who care to have HTTP header semantics show up in other environments can do various things (eg. reflect into an XML namespace). But it doesn't seem to me to be core business of the AtomPub WG to do this work... [googles a bit] OK it looks like Gnutella also uses HTTP for the file download part of it's protocol, fwiw. (including Range: header) http://www9.limewire.com/developer/gnutella_protocol_0.4.pdf Dan
Re: Autodiscovery
* Eric Scheid [EMAIL PROTECTED] [2005-05-05 02:35+1000] On 4/5/05 11:11 PM, Robert Sayre [EMAIL PROTECTED] wrote: The autodiscovery spec is a reasonable interpretation of the *one line* definition of the 'alternate' relation. how is a feed of recent entries a substitute version for the document in which the link occurs when that document is some blog post long since dropped out of the feed? Because the HTML definition is close to meaningless. I can substitute any document for another, and the 2nd is a substitution not through any intrinsic characteristics, but because it was substituted. Many of the HTML link type definitions don't bear up under detailed scrutiny... Dan
Re: PaceCoConstraintsAreBad
* Robert Sayre [EMAIL PROTECTED] [2005-04-07 17:22-0400] Sam Ruby wrote: Whether it is for accessibility, or for general usability, I want to ensure that every entry has a textual, non-remote component to it. +1 Yeah, but we can't really legislate that, can we? We are making editorial decisions for publishers via validity constraints. This sounds roughly the same as requiring title in HTML, eg. http://www.w3.org/TR/html4/struct/global.html#h-7.4.2 in that you can force documents to have some kind of title, but you can't legislate them into having sensible, accurate, etc titles. The schema can nudge people in the right direction though... Dan
Re: s/url/web/
* Tim Bray [EMAIL PROTECTED] [2005-03-17 16:27-0800] EDITORIAL: There are a couple of places where we use uri in the markup, specifically the atom:uri element (3.2.2) and the uri attribute of atom:generator (4.2.5). In both cases they're not actually URIs, they're IRIs, so the name is WRONG, except for nobody knows what an IRI is so renaming them iri would be confusing, and anyhow everyone thinks of URLs not *RIs, but naming them url would be wrong too, so why don't we actually change them to say what they're there for not what their syntax is and use web in both cases? -Tim +1 Dan ps. 'email' in the Person construct could also be handled by 'web' (or 'url/uri/iri') using the mailto: scheme, if only multiple of these were allowed per person-like-thing.
Re: s/url/web/
* Bjoern Hoehrmann [EMAIL PROTECTED] [2005-03-18 11:13+0100] * Tim Bray wrote: There are a couple of places where we use uri in the markup, specifically the atom:uri element (3.2.2) and the uri attribute of atom:generator (4.2.5). In both cases they're not actually URIs, they're IRIs, so the name is WRONG, except for nobody knows what an IRI is so renaming them iri would be confusing, and anyhow everyone thinks of URLs not *RIs, but naming them url would be wrong too, so why don't we actually change them to say what they're there for not what their syntax is and use web in both cases? -Tim We can call those at or about or internet but certainly not web. While we're at it, we can relive 10-15 years of URN vs URI debates on the Atom list instead of shipping product. Are you appealing to some notion of 'online' versus 'offline' resource? A spec could be cited from the formal Atom spec? Such distinctions are notoriously hard to maintain... If you want to add an implicit (and imho illadviced) notion of 'URI dereferencability' into the spec, it'd be good to see candidate text for inclusion, rather than doing it via attribute/element name choice. Note that the deferencability of identifiers changes over time, as infrastructure is deployed (or rots away); eg. DOIs, gopher:, java: URIs... Dan
Re: s/url/web/
* Antone Roundy [EMAIL PROTECTED] [2005-03-18 08:41-0700] On Friday, March 18, 2005, at 04:24 AM, Dan Brickley wrote: URIs and IRIs are the way we identify things (on, in, to and for...) the Web. So web to me seems natural. I think the question is which of these is meant by the web: a) HTML over HTTP(S), plus images and other things that get rendered in HTML documents b) everything with a URL, and the network those things are accessed over c) the internet I encourage Atom to follow the WebArch REC, let's call it (d), http://www.w3.org/TR/webarch/#intro [[ The World Wide Web (WWW, or simply Web) is an information space in which the items of interest, referred to as resources, are identified by global identifiers called Uniform Resource Identifiers (URI). ]] c) has entered common usage, at least among the general populous, but technically, a) or b) would be more accurate. I've always thought of the web as a), but while a) is certainly the core of the web, I suppose it makes sense to think that the web encompasses other things that a) is able to connect you to. Yes, I think that's the webarch line too. If HTTP went away, and we all used ftp:, freenet: or gopher: systems, and wrote our docs in SVG instead, it'd still be the Web. So (a) is the current core of the Web only in very pragmatic, market-based terms. You're also right that (c) is common usage. I've lately taken to asking non-geeks about their use of the Web. Often as not, they respond with what, you mean The Internet? yeah, I use that, Going with Webarch's (d), I think fits with using 'web' within the Atom spec... it's neutral in ways that avoid debates that typically chew up time on the URI mailing list. Dan
Re: BAG Question: What is a feed? Sliding-Window or Current-State?
* John Panzer [EMAIL PROTECTED] [2005-02-06 13:58-0800] Since an entry is identified uniquely by its atom:id (though it can have different states at different times); As I understand the Web, the REST concepts that underpin HTTP are quite happy with their being multiple representations of the selfsame resource *at the time*. The state captured in the documents that fly around the Web can be one of several that are associated with a common abstract entity. I'm not sure how this fits with the sliding window vs current state views of Atom. I guess I've always seen feeds as just being documents that are about some other documents, and whose state and selection of document coverage / detail is naturally going to vary depending on the sort of site we're dealing with. Dan
Re: Entry order
* Tim Bray [EMAIL PROTECTED] [2005-02-05 08:40-0800] On Feb 5, 2005, at 5:36 AM, Danny Ayers wrote: On Thu, 3 Feb 2005 23:21:50 -0500, Bob Wyman [EMAIL PROTECTED] wrote: Ordering of the element children of atom:feed element MUST NOT be considered significant. +1. +1 - I don't care whether we say MUST NOT, or the other wording floating around about this specification assigns no semantics, but I am 100% against assigning any meaning to the order in which things appear in the feed. +1 Although I could've lived with order being declared meaningful. The worst case is when it isn't clear whether ordering info must be preserved. Aside: sometimes in RSS1 item order relates to characteristics of the things described by the documents in the feed, rather than the docs directly (eg. job adverts, upcoming movies, ...). Dan Dan
Re: Dereferencing Identity Constructs
* Henry Story [EMAIL PROTECTED] [2005-01-31 16:25+0100] On 31 Jan 2005, at 05:22, Tim Bray wrote: On Jan 30, 2005, at 7:10 PM, Paul Hoffman wrote: The content of an Identity construct SHOULD NOT be dereferenced, even when it comes from a normally dereferencable scheme. There is no requirement for the content to represent a URI where a version of the feed or entry may be found. I'm +1 on this, -1. And I *will* lie down in the road. -1 also; showstopper broken imho (sorry to reply late in the thread; nearly missed this) dan
Re: PaceFormatSecurity
* Asbjørn Ulsberg [EMAIL PROTECTED] [2005-01-29 06:05+0100] On Fri, 28 Jan 2005 17:01:06 -0500, Robert Sayre [EMAIL PROTECTED] wrote: I guess the question is whether we can and should outline HTML security issues. I don't think we can or should. Considering the large amount of (X)HTML that are being syndicated via RSS and Atom today and will be in the future, I think we should. (X)HTML will be the main markup used inside all Atom Text Constructs, and while MathML, SVG and other markup languages we don't know about may contain security issues, they aren't nearly as important to mention as those that lie within (X)HTML. As far as SVG goes, I suspect a lot of the issues will be around Javascript, just as in (X)HTML. Dan
Re: PaceEnclosuresAndPix status
* Ray Slakinski [EMAIL PROTECTED] [2005-01-25 10:40-0500] +1 from me, I'm happy to see this added! +1 likewise to http://www.intertwingly.net/wiki/pie/PaceEnclosuresAndPix Dan On 24-Jan-05, at 7:18 PM, Tim Bray wrote: If there were no further discussion: Got no -1's, seems useful, needed for feature parity with RSS2, will likely go in absent some objections. -Tim
Re: PaceExtensionConstruct status
* Joe Gregorio [EMAIL PROTECTED] [2005-01-24 20:44-0500] On Mon, 24 Jan 2005 20:41:40 -0500, Sam Ruby [EMAIL PROTECTED] wrote: Joe Gregorio wrote: +1 to the general Pace, but I would prefer to see the 'Simple Extension' dropped. It adds a level of complexity that isn't requried. and for no discernable benefit. For example, the Pace states that A Simple Extension construct MUST NOT have any attributes or child elements. Does that mean that a Simple Extension can't use xml:lang? Does a formerly Simple Extension become a Structured Extension if it requires internationalization? I work best with specific example. How should wfw:comment be handled? As a Structured Extension. Is there a benefit to being a 'Simple Extension' that I am missing? Is it that they're unconstrained enough that one might hope to generate a UI for any simple extension without knowing much about the particular properties being used? Answering a question with a question, Dan
Re: AtomOWL AtomIsRDF
* Henry Story [EMAIL PROTECTED] [2005-01-17 16:12+0100] I have put up two pages (Paces) on the wiki. One AtomOWL [1] just is a place to work on the latest RDF model of Atom, and fulfill the requirement that Atom have a model. The Other AtomIsRDF [2] is a place to track the way for Atom to fulfill its extensibility requirements, by closing the gap with RDF. As you will see there is not a lot of difference really. So this should harm no one, but make it much easier to extend atom in a failsafe way. I fear [2] is unfortunately named. Atom is RDF-like in some ways, but until the Atom spec says Atom is RDF, Atom isn't RDF. A surface similarity to RDF's XML encoding, or even to RDF's graph data model, isn't by itself enough to declare that Atom is RDF. For example, there have been threads here about defaulting, about data being implied if missing, and other things that have no clear RDF equivalent. The name Atom is RDF goes somewhat against the decision record of this group, which has been pretty clear in its non-RDFness. Wiki style tends towards the consensual, so I suggest renaming it to AtomRDF or similar. Even as an RDF enthusiast, I find the name problematic. So I'm concerned that Atom is RDF will annoy people needlessly, which would be a shame since the work you've been doing on an RDF/OWL view of the Atom format is both interesting and valuable. Dan Henry Story [1] http://www.intertwingly.net/wiki/pie/AtomOWL [2] http://www.intertwingly.net/wiki/pie/AtomIsRDF
Re: The Atom Format end-game (PICS)??
* Bob Wyman [EMAIL PROTECTED] [2005-01-09 01:42-0500] Tim Bray wrote: 2. We are close to RSS2 feature-compatibility, we either adopt image enclosure or make a conscious decision not to. There are other bits of RSS2 that should be seriously considered -- even if they aren't widely used. For instance, the RSS2 rating element which contains a PICS[1] statement. As far as I know, virtually noone uses the rating tag in RSS2.0. Nonetheless, it would probably be wise to support such a thing in Atom. As blogging goes mainstream, we should be able to show that mechanisms at least exist to do what PICS is attempting to do... I agree that it should be possible to do PICS-like stuff in RSS and Atom feeds. I'm not sure you need a PICS tag in the core spec though. Various folks in Europe and Japan (eg. ICRA, IAJapan) are looking into PICS-like functionality in an RDF and XML environment, with use cases that go somewhat beyond the classic filtering / 'child protection' scenarios that dominate public perception of PICS. Historical aside, the original name for RDF was PICS-NG, an effort which was merged with Guha and TimBray's MCF-in-XML ideas. I'd argue that any PICS-ish functionality in 2005 can be accomplished using namespaces, and probably using RDF/XML-oriented namespaces, and that PICS itself is a legacy that doesn't need to be supported in the core Atom format. Of course if there are folks out there who really want to produce and consume PICS s-expression syntax in feeds, they can invent a namespace'd construct that allows such embedding. There are actually a few things PICS can do which XML and even RDF/OWL don't do well yet, in particular the ability to write a content label with a rule that explains how it applies to all documents that share a common base URI. But some of are working on an XML/RDF-ization of this. Details hopefully to follow soonish... Dan bob wyman [1] http://www.w3.org/PICS/
Re: arbitrary limitations in Person
* Tim Bray [EMAIL PROTECTED] [2005-01-04 07:38-0800] On Jan 4, 2005, at 1:39 AM, Henry Story wrote: I was just looking closely at the atom:Person class [1] and found some pretty arbitrary limitations: - why should a Person only have one e-mail address? - why should a Person only have one associated url? (s/url/uri/) It does seem to me that this will make an implementor's life a little easier. -Tim So long as these Person-descriptions aren't expected to be complete, it seems a reasonable approach. The atom:uri (homepage or weblog) is a reasonable place to go rummaging for more info about the identified Person. While I like the RSS1 flexibility to include more details inline (eg. foaf:workplaceHomepage, for aggregating feeds by employer), it's perfectly reasonable to partition the work differently, and push the flexibility off to other document formats. From an RDF perspective, it would be good to be able to consider the Atom:Person 'uri' and 'email' constructs to be inverse functional properties[1]. This is a guarantee that, properly used, these fields should identify at most one thing that has any given uri, or any given email. In other words, given any value that has correctly appeared as an Atom:Person url or email, there should be no more than one thing it could possibly be the url or email of. This makes it much easier on aggregators, but to possible annoyance of folks who have communal mailboxes and homepages. Revisiting [3.2: Person Constructs] of http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-03.txt 3.2.3 atom:email introduces a redundancy, since 3.2.2 atom:uri allows for mailto: URIs. Being able to pick out an email address without doing URL analysis seems worthwhile enough that the redundancy has value. But perhaps a note on this would help: a rough proposal: 3.2.2 NOTE: Although mailto: and other messaging-related URIs are technical in-scope for 3.2.3, the atom:email element SHOULD be used for a Person's email address, instead of using mailto: URIs in the atom:uri element. (Worth noting also that the spec also currently allows two emails to be stored, one as a mailto: in atom:uri, the other as atom:email. But you can't legislate against everything...). If atom:uri and/or atom:email could be used to unambiguously pick out some individual atom:Person, I'd be perfectly happy with the limited inline descriptions Atom allows, particular since namespace'd extensions are permissible. I'm not sure on the current definitions though - a URI associated with is loose enough that (for eg.) both Martin and myself could use atom:urihttp://www.w3.org//atom:uri without violating the spec. It's the nature of the association that's key. If the association can be specified as uniquely identifying, then aggregators can go rummage around that URI for more FOAF, vCard, XFN etc to flesh out the sparse inline description. At the moment FOAF has two properties somewhat akin to atom:uri, the foaf:homepage and foaf:weblog properties. I've often wondered about a common superproperty (since distinguishing homepages from weblogs is tricky anyway) but just couldn't think of a good name. The simplest fix I can think to propose at the moment is: 3.2.2 s/a URI associated with/a URI uniquely associated with/ ...though I fear uniquely might need some more definition, along lines of Any URI used as the value of an atom:uri element MUST be a URI of a single identifiable entity (Person, corporation or similar entity). (I make the word of do a lot of work here; in FOAF we say weblog of, homepage of which may or may not be close to this WG's thinking). cheers, Dan [1] OWL/RDF jargon. See http://rdfweb.org/mt/foaflog/archives/2003/07/10/12.05.33/ for fairly detailed walk-thru of how this is used in FOAF for identification-via-description.
