WWW 2006 Developer Track - Call for Developer Submissions
Apologies for cross-posts. The full call is below (and at http://www2006.org/developers/cfp.php), but in short we're looking for developers to present cool stuff. It can be anything from a 5 min lightning demo to a 30 min presentation. Of particular relevance here are the Next Wave sessions : an umbrella for all those Web 2.0 and Semantic Web things like blogging, microformats, Atom, Ajax, JSON, mashups, RDF/OWL, SPARQL... The deadline for proposals is the 19th March, but all we're looking for at this point is a short description (see below). - The developers' track consists of presentations by developers for developers. The audience is expected to be technically capable, and wanting to see a 'wow' factor with new functionality. Technical nitty-gritty is encouraged. Demos are good. Lightening talks consisting entirely of a demo are encouraged. To present your work on the developers' track, please respond to this call for submissions, by giving us a short description of what it is you would like to present, how long a presentation you would like to give, and indicate for which session(s) it would be appropriate. Submissions are made by email to the Developer Chairs ([EMAIL PROTECTED]). Please send the following information: * Contact information * Presentation title * The preferred length of the presentation * The possible length of presentation, list all that you are willing to accept. lightning No more than five minutes, for a quick demo. Please choose this option, even if you would prefer to give a longer presentation. Not choosing this option indicates that you do not want to give a lightening talk, even if there is not space for you to give a longer talk. 10 minutes 20 minutes The current intention is to mainly have 20 minute presentations. 30 minutes * Session(s). Choose at least one session. List all sessions for which you think your submission is appropriate. Note: the final decision on which sessions will run has not yet been made, and will depend in part upon the submissions received. The sessions are as follows: + Mobile + Society + Health + Education + Science + Security + Online Media + Next Wave Web Technologies + Ontologies and Semantic Web + XML technologies: XSLT2, XQuery etc. * Some other material. This can be: + Short description, e.g. one page for a lightening talk, two pages for anything else. (This is best) + Slides: e.g. one or two slides for a lightening talk, ten or twelve for a longer talk. + A demo. This should be submitted as screen shots, with a short description. It is also possible to give a URL for your code/demo. (Unless you already have this material available, you are discouraged from creating it for submission). This other material should be in any of the following formats: + plain text + PDF + PNG, GIF, JPEG + Powerpoint (not preferred) + Word (not preferred) If you have more than one file to submit, please create a zip archive. Send a single file, or the zip, as an attachment with your proposal. If the attachments are too large, send an URL to them instead. * Optionally a URL to your demo or code The submissions deadline is March 19th (midnight in Hawaii). Special Low Rate for Independent Developers (limited availability) -- We are pleased to be able to offer a special very low rate for independent developers presenting on the developers track. This is available only for self-financing developers (i.e. not receiving expenses from their employer or university), who are giving presentations on the developers track (including lightening talks). The rate is optionally: * a free One Day Attendance for the day that the developer is participating, or * £199 for a Standard Passport conference registration for the whole week. This rate is obtainable by email application to the Developer Track Chairs along with a presentation submission (see below). The chairs thank Hewlett Packard for their generosity in sponsoring this rate. -- http://dannyayers.com
Re: Browser behaviour
On 2/1/06, A. Pagaltzis [EMAIL PROTECTED] wrote: How about this simple rule? If the request for a feed has a referrer, which aggregator presumably[1] never do, then serve as `application/xml` with all cache control headers set to expire immediately; otherwise, send as `application/xhtml+xml`. (Expiry prevents intermediaries from caching it with the wrong MIME type.) [1] My server logs confirm this assumption for at least 20 different popular aggregators. Cunning, but the result of presuming aggregators never do might mean aggregators never can, and referrer refs. from aggregators may well be useful. Cheers, Danny. -- http://dannyayers.com
Re: More on atom:id handling
On 2/1/06, A. Pagaltzis [EMAIL PROTECTED] wrote: * David Powell [EMAIL PROTECTED] [2006-02-01 17:10]: On the contrary, I have a problem with preventing multiple revisions from having the same atom:updated value. But then you have no idea which revision will be picked by clients that try to show the latest one, which to me sounds like it fulfills the criteria for a potential interop problem, which is exactly what SHOULD is about, so I think this was the right choice. It's not straightforward, this came up pretty quickly in the Atom/OWL efforts. As Bill said, it's a composite key. In RDF/OWL that has so far demanded a rule* - somewhat less convenient than having a single URI as id. The question is, from what is the composite key formed? id certainly, updated too - but is same id+updated enough? What if other parts of the entry differ? Different xml:lang even...same entry or different? *see also : http://esw.w3.org/topic/CIFP Cheers, Danny. -- http://dannyayers.com
Browser behaviour
The mail below is from the WordPress list, they're discussing including stylesheet references in Atom docs. Have we got anything like best practices or more palatable workarounds for these circumstances? (i.e. in addition to using application/atom+xml) -- Forwarded message -- From: Pete Prodoehl [EMAIL PROTECTED] Date: Jan 30, 2006 4:24 PM Subject: Re: [wp-hackers] XSLT: Sample implementation To: [EMAIL PROTECTED] David House wrote: Some problems: 2) Atom support isn't there. Firefox and Konqueror (the browsers I tested in) get scared off by Atom's mime type and prompt the user to download it. They don't recognise it as XML, so they don't transform it. We have two options here: give up or serve as text/xml (I guess the latter won't be too popular). Really, browsers should recognise application/atom+xml as something they can parse as XML and do so. That's why I eventually gave up using application/rss+xml and switched to text/xml for RSS. Maybe it's time to do the same for Atom? Pete ___ wp-hackers mailing list [EMAIL PROTECTED] http://lists.automattic.com/mailman/listinfo/wp-hackers -- http://dannyayers.com
Atom2RDF via Universal Feed Parser
fyi, Chimezie has a blog post [1] including the mapping below between Atom as interpreted by Mark Pilgrim's UFP (so it'll also work for anyRSS) to RDF. The target app is Emeka, an RDF IRC Agent which uses 4Suite/Versa, though presumably the same approach could be taken with Redland (via Python binding) or RdfLib for model/persistence. Whatever the RDF API, it could form the basis of an Atom Store. At some point it'll probably be a good idea to capture the mapping from the core Atom constructs (as expressed in Atom/OWL [2]) to the other vocabs/ontologies used - FOAF, SKOS, DC, presumably through owl:equivalentClass/owl:equivalentProperty statements. (APP construct mappings to follow, when someone's got a bit of time...) Each entry is an instance of (atomOwl:Entry,rss:item) * The URL of the feed - an instance of atomOwl:Feed * Feed - atomOwl:entry - entries * entry (link or id as URI) - rdfs:label,skos:prefLabel,dc:title - entry.title * entry - dc:description,atomOwl:summary,rdfs:comment - entry.summary * entry,feed - dc:creator, foaf:maker - foaf:Person * entry.author_detail.name - foaf:name * entry.author_detail.email - foaf:mbox * entry.author_detail.href is the URL of the author * entries.tags - skos:Collection * entries.tags.label - skos:prefLabel * entries.tags.scheme + entries.tags.term (URI resolution) - URI of skos:Concept * entry - dc:created,dc:date,atomOwl:published - entry.published [1] http://copia.ogbuji.net/blog/2006-01-28/A_univesal [2] http://pragmatron.org/trac/file/pragmatron/atom-owl/AtomOwl.n3 -- http://dannyayers.com
Spec wording bug?
In draft-ietf-atompub-format-11 under 4.2.7 The atom:link Element, compare and contrast: [[ 4.2.7.4 The hreflang Attribute The hreflang attribute's content describes the language of the resource pointed to by the href attribute. ... 4.2.7.6 The length Attribute The length attribute indicates an advisory length of the linked content in octets; it is a hint about the content length of the representation returned when the IRI in the href attribute is mapped to a URI and dereferenced. ]] I believe the language of the resource for hreflang makes no sense - it will be the *representations* that are associated with languages, and the implies a single language - there may be more than one. Cheers, Danny. -- http://dannyayers.com
Re: Spec wording bug?
On 10/14/05, Robert Sayre [EMAIL PROTECTED] wrote: I don't understand the second issue being raised here. Could someone try again? Robert - sorry, I obviously wasn't very clear. I only wished to bring a single issue to the list's attention, the discrepancy between the wording of the spec on hreflang, and what I believe to be its intended meaning in particular in terms of one of the cited references (RFC 3986). 4.2.7.4 The hreflang Attribute The hreflang attribute's content describes the language of the resource pointed to by the href attribute. A resource in the sense of RFC 3986, as far as I can tell, may have multiple representations associated with any number of languages. As far as I'm aware, the only connection between the language(s) and the resource is through the representation(s). This view is reflected in the the other piece of the Atom spec I quoted: 4.2.7.6 The length Attribute The length attribute indicates an advisory length of the linked content in octets; it is a hint about the content length of the representation returned when the IRI in the href attribute is mapped to a URI and dereferenced. ]] Antone - I could be wrong, but I don't think this is a content negotiation issue, simply that the wording munges the resource with its representation(s). I believe this inconsistent with the WebArch conceptual model assumed by the rest of the Atom spec, and actually inconsistent with that other definition inside the spec. Paul - as I understand it the content isn't identical with the resource. This distinction may appear picky, but given that the other definition quoted manages consistency with the referenced specs, it appears to be possible without much extra effort. I must confess I have no idea of the IETF line on where accuracy ends and pickiness begins, or what might be appropriate action under the process - on that I will happily defer to you. I'm afraid I don't know what you are referring here: DA: and the implies a single language - there may be more than one. PH: That's true. And it matches the XML 1.0 spec exactly. Cheers, Danny. -- http://dannyayers.com
Re: Top 10 and other lists should be entries, not feeds.
On 8/31/05, Danny Ayers [EMAIL PROTECTED] wrote: Correction: I doubt there's much difference in terms of effort needed to support either the per-entry or in-entry approaches. Capabilities of the client might make a lot of difference though = I doubt there's much difference in terms of effort needed for a publisher to support either the per-entry or in-entry approaches. Capabilities of the client might make a lot of difference though Also what I didn't ask was - as these approaches are already supported by the Atom format, what's the point of dispute, the aim of this discussion? Cheers, Danny. -- http://dannyayers.com
Project descriptions with Atom
DOAP is Description of a Project, done in RDF. CodeZoo are using Atom as a format to receive project updates, using DOAP RDF/XML as a payload. Details - -- Forwarded message -- From: Edd Dumbill [EMAIL PROTECTED] Date: Aug 3, 2005 10:46 PM Subject: [doap-interest] CodeZoo launches DOAP support To: [EMAIL PROTECTED] http://usefulinc.com/doap/news/contents/2005/08-03-codezoo/read O'Reilly's [1]CodeZoo has just launched a major deployment of DOAP. CodeZoo is a software registry for code libraries, covering Java, Ruby and Python. Each entry in the registry has a DOAP export available. Additionally, developers can provide CodeZoo with an Atom feed containing embedded DOAP. This means the repository can be kept up to date with releases. More information: * [2]DOAP in CodeZoo * [3]DOAP over Atom * [4]Keep CodeZoo up to date with DOAP References 1. http://www.codezoo.com/ 2. http://ruby.codezoo.com/about/doap.csp 3. http://www.codezoo.com/about/doap_over_atom.csp 4. http://www.codezoo.com/cs/user/create/doap_feedback ___ doap-interest mailing list [EMAIL PROTECTED] http://lists.gnomehack.com/mailman/listinfo/doap-interest -- http://dannyayers.com
Re: spec bug: can we fix for draft-11?
On 8/2/05, Bill de hÓra [EMAIL PROTECTED] wrote: Graham wrote: From atompub-format-10, 4.2.6: Its content MUST be an IRI That to me is demonstrates a very clear intention of the working group that the content must be exactly equal to the IRI. My reading too. I don't want to allow whitespace. But this id urn:foo /id is going to happen, is going to cause problems, and working around it does not strike me as being something you can foist entirely onto the spec's end-users. Why is it particularly likely to happen? I don't really understand why this should be treated any differently than the numerous other problematic things that could happen if one doesn't take the spec literally. (I'd suggest spec prose trumps RNG grammar, as there's a lot of other stuff not expressable in the grammar). But now the issue has been raised, it does seem reasonable to add a note (assuming the process is ok for that) to the effect that stray whitespace in content is an error. I can't see how it can be desirable to allow it (though am not given to lying in the road). At the application level we're back to Postel again - publishers shouldn't pump this stuff out, but liberal clients may find it useful to trim whitespace from IRI and date fields. But surely that's outside the scope of the format spec itself. Cheers, Danny. -- http://dannyayers.com
Re: Introduction to The Atom Syndication Format
Looks great. My only suggestion would be to expose the MUSTs etc. little more, especially where Atom differees from RSS. E.g. right now it would be easy for someone coming from RSS 2.0 to think that id was the same as guid. So in this case maybe: Identifies the feed in a universally unique and permanent way. = Identifies the feed in a universally unique and permanent way, using an IRI. or perhaps Identifies the feed in a universally unique and permanent way, according to rfc3987. Cheers, Danny. -- http://dannyayers.com
Re: Atom RDF/OWL models
On 7/24/05, Ian Davis [EMAIL PROTECTED] wrote: Don't forget danbri's Atom/RDF subset[1]. It's not a translation but it's worth attempting to interpret it using one of them. Thanks Ian, I assumed everyone already knew about that ;-) Anyhow I've dumped the list onto the ESW Wiki: http://esw.w3.org/topic/AtomRdf Additions and gardening appreciated. Cheers, Danny. -- http://dannyayers.com
Atom RDF/OWL models
Hi folks, I'm trying to collect a list of mappings Atom - RDF/OWL. Anyone that has such a thing, can you please drop me a pointer to the latest version(s) of any schemas, XSLT or whatever you might happen to have lying around. Notes on how current they are, or anything else of relevance appreciated. So far I've got the following: Henry Story's material, mostly (I think) looking for a direct mapping with a Atom-specific vocabulary (there's also his BlogEd material, on using Atom/OWL as the internal representation in a blogging tools). I'm not sure, but this might be OWL DL. Most recent date mentioned is 2004-11-09, not sure which is the latest Atom draft covered. http://bblfish.net/work/atom-owl/ David Powell's full and fairly verbose RDF schema, again I think it's an Atom-specific vocab : http://djpowell.net/atomrdf/0.1/ Dates from 2005-03-22, covers draft-05. it can be viewed through a nifty little styled-TriX converter: http://djpowell.net/rdftrix/ Dave Beckett's got support for Atom 0.3 in Redland (RDF toolkit), specifically in the Raptor Parser kit - he's currently looking to update this to 1.0: http://librdf.org/raptor/ Mark Nottingham's talked about Atom/OWL in the context of his sparta.py simple API for RDF, not sure if he's done a schema: http://www.mnot.net/blog/2005/03/17/sparta Mark Woodman has done some work with Atom + Jena, producing JavaBeans. http://inkblots.markwoodman.com/index.php?p=13 My own notes+ XSLT+schema, old old old, pre-0.3 I think. I'll update all this asap with whatever I can gather. http://semtext.org/atom/ There are also some very early ones around Sam's blog somewhere - I seem to remember one that attempted to map all the Atom constructs to existing vocabs, DC etc. (I've a feeling that put a lot of folks off RDF/XML ;-) I think Aaron S. and Norm W. have both a mapping or two. Bet sbp's got one too. http://www.intertwingly.net/blog/ Cheers, Danny. -- http://dannyayers.com
Re: [rss-media] Re: Media extensions
On 7/18/05, Robert Sayre [EMAIL PROTECTED] wrote: Media RSS already has an effective editor who is also a good listener: Yahoo's David Hall. If the Media RSS folks (or some other constituency who've done their homework) want to use this WG as their venue, that would be great. If not, I would be opposed to modifying the charter. That seems like self-perpetuating bureaucracy. Another way of putting it would be that, absent new participants, I favor completing the autodiscovery and protocol drafts and closing the WG. +1 I suspect the accumulated WG fatigue means probably the only viable route would be with the help of new blood. That isn't to suggest a completely new WG might not be appropriate, I honestly don't know. It might be that all is needed that the model described in Y!mRSS be abstracted from the RSS 2.0 specifics, then re-expressed as Atom RDF. Given that Atom (and RDF) both have fairly clean extension mechanisms, it shouldn't be necessary to cover every edge case in the 'primary' media extension, just get the core down. Cheers, Danny. -- http://dannyayers.com
Evangelism, etc.
If I could distract folks from the champagne and crudities for a moment: First - I just received a rewrite of the spec draft in nicely-styled XHTML 1.0, from someone (who wishes to remain anonymous) who refers to the IETF docs as so 1989 - http://dannyayers.com/atom/draft-ietf-atompub-format-10.xhtml Second - I just read 3 reviews of Atom (linked from Dave Winer's blog) containing significant criticism, much of it valid. However the target of these posts wasn't Atom itself, but the 'RSS 2.0 and Atom Compared' doc (on the Wiki/Tim's snapshot). It does make sense to make the info available in a friendly fashion, but in this case it seems to have backfired. A suggestion for subsequent material - assume the RSS community doesn't know the difference between normative and informative. Third - any suggestions for something useful to do with the 'Finally Atom' blog/data [1]? I set it up on a TypePad account when they were beta, but have been paying for it since they came out of beta. I can't really justify the expense any more, especially since I don't really have time to make it any more interesting than endless 'X supports Atom'. (I don't think the protocol needs promotion in the same way as the format did). On a not-unrelated note - who's the best contact for atomenabled.org? Cheers, Danny. [1] http://danja.typepad.com/fecho/ -- http://dannyayers.com
Re: Media extensions
On 7/16/05, A. Pagaltzis [EMAIL PROTECTED] wrote: * James M Snell [EMAIL PROTECTED] [2005-07-16 20:05]: If the community can drive a viable solution without the overhead of a formalized standardization process, it will work out best for everyone and the anti-formal-standards crowd will have far less to complain about or will at least be able to devote more time to bashing atom ;-) Yahoo!'s approach did seem to work very well without any formal process, effectively just a mailing list and editor. But then Apple came along... Yeah – wasn't the idea about specifying extension mechanisms so thoroughly in the Atom format spec that it would allow anyone to bolt on things via a variety of available hooks, ad-hoc, without needing to define semantics and having worry about interop anew each time? Indeed it was. But for the extensions themselves, there is still plenty of scope for poor design and near-(but not quite)-duplication of work. I'm honestly not sure there's any group activity that could help, but while there are still people in the room I think it's worth considering. *If* a WG-like approach to media in Atom was the best approach, now would be the time to do it. A strong base spec should be able to carry organic growth without requiring reliance on the legitimization of a standards body to make things work; legitimization can be granted retrospectively by writing down existing practice. (I am reminded of Shirky's praise of evolvable systems. And heck, Atom itself is an example of this.) So yeah, I don't Yahoo or Apple need to be pushed towards a standards body. It would be enough if are willing to iterate their specs before finalizing them, with input from a crowd of eyeballs. Apple seems willing to do that now; John Gruber argues it's because they were scampering to get to the market with podcasting in iTunes. Ah, that's good to hear. Yahoo has been, from the start. I think the timing for Atom going gold couldn't have been much better; had it taken a bit more time, then all discussion of the podcasting and media extensions would have had to revolve solely around RSS since there wouldn't have been any Atom format to think about. Hmm, how podcasts are there? How many are in Atom? How do you even *do* a podcast in Atom? (This is kind-of what I'm trying to get at ;-) What clients support podcasts in Atom? We should be glad that the spec was pushed through at the final stages; a tip of the hat to the WG chairs and members who insisted on making haste with a Good Enough text. Yep, good men. Cheeers, Danny. -- http://dannyayers.com
Re: Evangelism, etc.
On 7/16/05, Robert Sayre [EMAIL PROTECTED] wrote: On 7/16/05, Danny Ayers [EMAIL PROTECTED] wrote: Second - I just read 3 reviews of Atom (linked from Dave Winer's blog) I found the criticism pathetic. Well, yes, but you're more familiar with the reality than most people that are likely to read that post. As for Alex Bosworth's post, a commenter said This post is rubbish and way off base. I'm inclined to agree. Seems like a publicity stunt. Quite possibly. But such things will influence the adoption of Atom. Put it this way - there are millions of RSS 1.0 feeds out there, and pretty much all tools support it. Yet even well-informed people are pointing to RSS 2.0 and Atom Compared as if there were no other alternative. I hardly think RSS 2.0 has gained the popularity it has through technical merit. Cheers, Danny. -- http://dannyayers.com
Re: Evangelism, etc.
On 7/16/05, Walter Underwood [EMAIL PROTECTED] wrote: But there is a point buried under all that. What are the changes required to support Atom? It looks complicated, but how hard is it? Here is a shot at that information. Thanks Walter, this is good... For publishers, you need to be precise about the content. There are fallbacks, where if it is any sort of HTML, send it as HTML, and if it isn't, send it as text. The XHTML and XML options are there for extra control. Also, add an ID. It is OK for this to be a URL to the article as long as it doesn't change later. That is, the article can move to a different URL, but keep the ID the same. Add a modified date. The software probably already has this, and you can fall back to the file last-modified if you have to. But if there is a better date available, use it. The ID and date are required because they allows Atom clients and aggregators to get it right when tracking entries, either in the same feed or when the same entry shows up in multiple feeds. Extending Atom is different from extending RSS, because there are more options. The mechanical part of extensions are covered in the spec, to guarantee that an Atom feed is still interoperable when it includes extensions. The political part of extensions has two options: free innovation and standardization. Anyone can write an extension to Atom and use it. Or, they can propose a standard to the IETF (or another body). The standards process usually means more review, more interoperability, and more delay in deploying it. Sometimes, the delay is worth it, and we hope that is true for Atom. Cheers, Danny. -- http://dannyayers.com
Re: Atom for RDF transfer?
On 7/10/05, Mark Nottingham [EMAIL PROTECTED] wrote: Hi Danny, What does Atom bring to the table here? Sounds like straight REST would do the trick admirably for you... Maybe, hopefully. I'm not sure whether an update (delete graphA, add graphB) could be better done with more 'memory' (state, I guess) that a series of simple metadata-stamped entries could supply. Cheers, Danny. -- http://dannyayers.com
Atom for RDF transfer?
While everyone's waiting for ratification of the Atom format, maybe there are a few brain-cycles that can be harnessed... What I (and others [1]) am looking for is a standard means of interfacing with an RDF store like Redland or Jena over HTTP. The operations required are: 1. query the store 2. add statements to the store 3. delete statements from the store 4. make an update to the store (5. sync stores) The first of these is reasonably well provided for already with SPARQL. There appears to be some commonality of aproaches to 2, 3 and 4, but no single standard seems yet to have emerged. 5. is something needed sometime before long, but could probably be fulfilled with the other points and an appropriate algorithm (possible approaches at [4],[5]). Now ideally all the operations would be done directly over HTTP, but there are one or two issues, and I'm wondering if the Atom format/protocol could form a consistent, easily implemented lightweight delivery mechanism as an alternative. It'd be tunneling, but without all the WS-* overhead. The interchange format specified for RDF is XML (i.e. RDF/XML) so that's the first hurdle hopped. This kind of thing is being covered to some extent by the W3C Data Access WG (DAWG) and Semantic Web Best Practices and Deployment WG, but they are tied to their charters. A good solution from left-field (built on good standards) could fast-forward development. So first the status quo, as far as I'm aware: 1. ask the store a query The SPARQL protocol and RDF query language [2] is emerging as the standard for queries, i.e. read-only operations. The query language itself is fairly SQL-like. The protocol as it currently stands has a generic WSDL 2.0 expression, but in practice *the* binding so far is to HTTP, using the query itself as a parameter in a GET: GET http://example.com/sparqlendpoint?query=...bunch of sparql... The results are returned as a XML doc in the response body, the format of which will depend on the nature of the query (there's a simple result-set format for SELECTs, RDF/XML for CONSTRUCT etc). The operations of 2, 3 and 4 can be covered by a protocol in a similar fashion: by supplying an RDF graph to add, a graph to delete, or a combined operation for update supplying a graph to delete followed by a graph to add. I'll just expand that a little before describing existing protocol support - 2. add statements to the store Data can be added to an RDF store by supplying a list of statements, that is the graph, as an RDF/XML doc. This is something all triplestores should support. 3. delete statements from the store This is a little trickier, there isn't any operation common to stores that says delete(graph). In practice this may mean listing and deleting the individual statements. I think there may be issues where the graph to delete matches a subgraph in the store where the nodes aren't sufficiently bound to URIs to make matching unambiguous. Frankly I'm not sure, but I don't think it would impact on the protocol. 4. make an update to the store A two phase operation, delete(graphA), add(graphB). It would be nice for this to happen as an atomic transaction. Ok, existing protocols/proposals include the NetAPI [6,7], and Joseki: RDF WebAPI [8] (I think this is currently moving over to SPARQL for queries, not sure about updates). The NetAPI use a two-part mime/multipart message with a HTTP POST, the first containing the graph to delete, the second containing the graph to add. Adding and deleting alone are special cases. (I seem to remember there being some issues relating to the use of mime/multipart around Atom, I can't for the life of me remember what they were). There's also URIQA, which can provide the operations listed, but is more aligned towards working with authoritative sources, i.e. where the host owns the resources identified. Technically it looks good, but involves the addition of extra HTTP methods, which has caused some controversy. So how might all this be done in Atom? I don't really know, beyond thinking perhaps that many of the interfacing operations with a triplestore may be exressed nicely as a sequence of entries, content as graphs, each entry representing an add/delete operation. Cheers, Danny. [1] http://lists.gnomehack.com/pipermail/redland-dev/2005-July/001019.html [2] http://www.w3.org/TR/rdf-sparql-query/ [3] http://www.w3.org/TR/rdf-sparql-protocol/ [4] http://www.w3.org/DesignIssues/Diff [5] http://www.dbin.org/ [6] http://www.w3.org/Submission/2003/SUBM-rdf-netapi-20031002/ [7] http://www.wiwiss.fu-berlin.de/suhl/bizer/rdfapi/tutorial/netapi.html [8] http://www.joseki.org/protocol.html [9] http://sw.nokia.com/uriqa/URIQA.html -- http://dannyayers.com
Re: Major backtracking on canonicalization
On 7/7/05, Bob Wyman [EMAIL PROTECTED] wrote: Paul Hoffman wrote: Now that I understand this better, I believe that our text should read: Thank you for catching this. You've saved us major pain! +1 -- http://dannyayers.com
Re: Clearing a discuss vote on the Atom format
+1 to Paul's suggestions, with the adjustments as suggested, worded as the editors feel comfortable. Without deployment of signed Atom to draw on this is unlikely to be perfect. Just do whatever it takes to satisfy the discuss. -- http://dannyayers.com
Re: Microsoft, RSS Atom
On 6/25/05, James M Snell [EMAIL PROTECTED] wrote: [snip] http://www-128.ibm.com/developerworks/blogs/dw_blog_comments.jspa?blog=351entry=84636. I generally agree. Strongly, when you talk of the best advocacy being through demonstration. The MS extension is a little unusual in that it impacts other elements (giving them a datatype), it's an architectural forms kind of thing. But I *think* it'll still play ok in Atom. Hopefully someone will have time to look deeper. Has anyone done Yahoo!'s Media RSS as Atom yet, btw? Other comments some links at: http://dannyayers.com/archives/2005/06/24/ms-rss/ Cheers, Danny. -- http://dannyayers.com
Re: Google Sitemaps: Yet another RSS or site-metadata format and Atom competitor
Ach, late to the thread again. When I saw Google Sitemaps I also thought of RDF Site Summary, and did a sitemap2rss.xsl. But as noted already the role of RSS has mutated from site summary to a content delivery format, so it wasn't a very good fit. But it was straightforward to take their data and express it as RDF in a more natural fashion, see: http://dannyayers.com/archives/2005/06/03/google-sitemap/ I think Atom could have been a good format for this purpose without the need for any other. I disagree with Walter, I believe the Sitemap terms are defined well enough to be reused. I've pasted that of priority below - it basically says where a crawler's resources are limited, URLs with a higher priority on a site should be crawled first/in preference to others on the site. That could be a nice like Atom extension. Cheers, Danny. - priority Definition Optional. The priority of a particular URL relative to other pages on the same site. The value for this tag is a number between 0.0 and 1.0, where 0.0 identifies the lowest priority page(s) on your site and 1.0 identifies the highest priority page(s) on your site. The default priority of a page is 0.5. Please note that the priority you assign to a page has no influence on the position of your URLs in a search engine's result pages. Search engines use this information when selecting between URLs on the same site, so you can use this tag to increase the likelihood that your more important pages are present in a search index. Also, please note that assigning a high priority to all of the URLs on your site will not help you. Since the priority is relative, it is only used to select between URLs on your site; the priority of your pages will not be compared to the priority of pages on other sites. -- http://dannyayers.com
atom:type, xsl:output
[forwarding for Jimmy, he's having mail problems] From: Jimmy Cerra [EMAIL PROTECTED] I'm a little confused by the type attribute for atom:content and other elements. This the following correct? * When @type=html then the content of the element is a xsd:string [1] of an HTML DIV element plus optional insignificant whitespace around it. Which version of HTML is defined? How do you differentiate between HTML 4.01, HTML 3.2, the upcoming HTML 5, or nonstandard HTML (like with marquee elements)? * When @type=xhtml then the content of the element is a xhtml:div XML fragment plus optional insignificant whitespace around it. Again which version of XHTML is defined? How do you differentiate between XHTML 1.0, 1.1, or 2.0? Since XHTML 2.0 may have a new namespace, so will you allow that? How does requiring XHTML:div impact which XHTML modules are required (I have a guess)? And what about exotic versions like XHTML+MathML+SVG or XHTML 1.1 plus MathML 2.0? (Some blogs actually use it XHTML 1.1 plus MathML 2.0!) * When @type=text then the content of the element is a xsd:string of a text/plain document. * When @type=mime/type [2], ONLY for atom:content, then the content (or src document) is that type of document. Why not allow other elements to use this? What about content that isn't compatible with XML 1.0 (like XML 1.1, Turtle, RTF, PNG); should it be entity encoded/put into cdata section like HTML? What should one do when encountering these situations? Does that mean that if you use application/xhtml+xml, you can do (rest of feed omitted for brevity): atom:content type=application/xhtml+xml html xmlns=... headtitle.../title/head body ... /body /html /atom:content How do you specify xml-stylesheets processing instructions, doctype and xml declarations, and other data about the content? PIs may be a non-issue if they are not read by the XML processor for the Atom feed; although, that isn't guaranteed. I think you should at least allow @type=xml, as others have suggested for xml 1.0 content, along with adopting XSLT's output attributes (perhaps not using @method or @media-type). This would ease the pain with XML, and all media/types for @type require the content to be xsd:string valid (that is, entity encoded or using CDATA sections). Sorry for the boatload of questions. -- Jimmy Cerra http://pawsgroup.blogspot.com [1] That is, a text node in the XML tree. [2] A mime type, noting the exception in 4.1.3.1.
Re: Author and contributor
I'm not 100% convinced of the need for contributor, but in the interests of consensus: +1 make atom:author plural +1 keep atom:contributor +1 punt bylines to an extension Cheers, Danny. -- http://dannyayers.com
Re: Compulsory feed ID?
On 5/19/05, Sam Ruby [EMAIL PROTECTED] wrote: Graham Park has proposed that we loosen the existing language to permit duplicate ids in the case where the entries have atom:source elements which identify different URI's in self links. I support this compromise and believe it should be supported by the WG and incorporated into the Atom Draft. I believe it makes sense to give the notional atoms (entries) individual identifiers which will be preserved globally, irrespective of the source, irrespective of where the entries are found - so yes, duplicate IDs in a feed seem an acceptable scenario. I don't personally care how it's done, but a reference back from the feed document to the URI from whence it is begetted is pretty essential for the easier one-click subscription strategies, and should come in handy later for aggregate-republish processing. I think a reference back to the source (original better, intermediate better than nothing) is also desirable to help reduce duplicate posts appearing in any end-of-chain UI. Take this scenario - two entries identical in every respect *except* for their ID. Any resource on the Web may have any number of different URIs, which suggests any entry might /potentially/ have any number of IDs. Should the two entries be allowed in the same feed? If you change the name of an entry, do you change its nature? Sorry, slipping, it's a bit late here - scratch the philosophy, ;-) Basically I reckon duplicate IDs in a feed are ok - leave it to the (final or intermediate) consumer to filter out if required according to local rules/heuristics. Cheers, Danny. -- http://dannyayers.com
Re: Atom 1.0?
Marketing: Atom Technical: Atom (RFC) +1 -- http://dannyayers.com
Re: Updated Atom2RDF stylesheet
On Mon, 21 Mar 2005 23:16:57 +, David Powell [EMAIL PROTECTED] wrote: I've updated my Atom to RDF/XML XSLT transform to implement draft-06. Great stuff! I've updated links etc. accordingly at: http://semtext.org/atom/ Anything needs adding there, please let me know. Cheers, Danny. -- http://dannyayers.com
Re: Person identity
The use cases are good, and even before you start looking at the relationship between entries and people there are limits to what you can do with the author/contributor constructs. This general issue has had 4+ years of hammering in theory and practical deployment around FOAF, which is been successfully used in RSS 1.0 feeds. This kind of data can be stored/queried reasonably efficiently in databases. There's a write-up Identifying things in FOAF: http://rdfweb.org/mt/foaflog/archives/39.html Cheers, Danny. -- http://dannyayers.com
Re: Person identity
On Sat, 19 Mar 2005 11:55:06 +, Bill de hÓra [EMAIL PROTECTED] wrote: Extend Atom with FOAF instead if you really need these capabilities in the near term. Yep, given the timescales involved, that sounds like a good pragmatic solution. Even if Atom doesn't support it, and feeds don't use the extension, your own database can implement something like FOAF smushing based on properties of entries. If you find two entries with an author (foaf:name) Bill de h#211;ra associated (directly or indirectly) with URI (foaf:homepage) http://www.dehora.net/journal/ then chances are it's the same person. Cheers, Danny. -- http://dannyayers.com
Re: Migrating extensions (was: [rss-media] Coexistence with Atom ?)
On Sat, 05 Mar 2005 09:45:56 -0800, Tim Bray [EMAIL PROTECTED] wrote: On Mar 5, 2005, at 6:25 AM, Graham wrote: I suggest we set up a panel to assess new extensions. They will solicit bids from all the major vendors for threading, video, audio etc and the best in each category will be chosen. If a vendor chooses to use there own extension over the one we choose for them, they will have just 48 hours until bombing commences. Damn good thinking. But bombing may be sub-optimal; how about retaining the services of a ring of ruthless hired killers instead? Yep. Even considering the economies outsourcing can offer, long term I bet employment of mercenaries works out cheaper than the programmers needed to support Nx(N-1) extensions... Cheers, Danny. -- http://dannyayers.com
Re: Migrating extensions (was: [rss-media] Coexistence with Atom ?)
On Thu, 24 Feb 2005 20:12:23 +, David Powell [EMAIL PROTECTED] wrote: One of the reasons for proposing PaceExtensionConstruct [1] was to allow existing RSS extensions and RDF properties to be used in Atom. If we have no model for extension elements, other than that they are bits of opaque infoset hanging in specific but meaningless places, then it seems that we need to redefine all existing extensions for use in Atom on a case-by-case basis. This thread seems to confirm that. Is that the best that we can come up with? Try asking again in a year or so's time, when we have an audio extension defined by Microsoft for Microsoft applications, a threading extension defined by Google for Google applications and a video extension defined by Yahoo for Yahoo applications. Case-by-case will favour those with the weight to ensure enough deployment to bootstrap general adoption. The long term network-effect driven gains of interop are outweighed by the short-term competitive advantage of features. Proprietary Atom solutions here we come! Cheers, Danny. -- http://dannyayers.com
Re: FotoNotes extension (was: AtomPubIssuesList for 2005/02/22)
On Wed, 23 Feb 2005 00:05:09 -0500, Robert Sayre [EMAIL PROTECTED] wrote: Paul Hoffman wrote: This is also a reasonable time to start creating format extensions and talking about them here. Here's one that's sort of done: http://fotonotes.net/spec/index.cgi?FotoNotesSpecification This is what will carry Flickr annotations, and they do it with Atom and RDF. They made a few mistakes. One of them centered around the purpose of atom:id. That means *smart people miss the point*, because it's a subtly different than RSS. I think starting the example atom:id with urn:uuid instead of vemmi://; would help quite a bit. Now the Tag URI scheme's [1] been approved by the IESG, maybe that's worth considering again. If I get chance I'll see what Yahoo's Media RSS looks like as Atom (it's currently written for RSS 2.0). I had a play the other day and it translated into RDF/XML with RSS 1.0 pretty nicely [2], I think it could also lend itself to being a fairly format-agnostic vocabulary in a similar manner to FotoNotes. Cheers, Danny. [1] http://www.taguri.org/ [2] http://dannyayers.com/archives/2005/03/01/yahoo-rss-media-as-rdf/ -- http://dannyayers.com
Re: Consensus call on last round of Paces
Hmm, I've been a little distracted, but I thought PaceExtensionConstruct did get a reasonable amount of support. +1 from me anyway. On Tue, 15 Feb 2005 11:12:48 -0800, Tim Bray [EMAIL PROTECTED] wrote: Methodology: Paul I went through *all* the WG emails that directly commented on the currently open issues (see http://www.intertwingly.net/wiki/pie/AtomPubIssuesList); in most cases the calls were pretty clear. As always, we may have mis-read the group, feel free to say so if you think so. The intent is that this email serve as guidance for the editors in preparing the format draft that we send out for IETF last call. We do not expect further material discussion of format-related Paces, it's now over to the whole IETF. On the other hand, discussion of editorial changes is always fair game, please keep reporting what you find to the list, and we wouldn't be surprised if the editors turned up some corner cases too. PaceAggregationDocument PaceAggregationDocument2 One -1, nobody unambiguously in favor. DISPOSITION: Close them. PaceAggregationInSeparateSpec Only a couple of voices in favor, some support conditional on profiles. DISPOSITION: Close it, but given that the other aggregation-related Paces seem to be failing, it seems like a separate spec is the only place that this kind of work gets done. PaceArchiveDocument A howling mob of sharp pointy -1's. DISPOSITION: Close it. PaceClarifyDateUpdated A couple of -1's, one fuzzy +1. DISPOSITION: Close it. PaceCollection One pro, one contra, not much discussion. DISPOSITION: Not enough support, close it. PaceCommentFeeds Two contra, one pro, some suggestion that we really need link/@rel=comment. DISPOSITION: Not enough support, close it. PaceDatesXSD Everyone seems to like it, enough people want the regex that it's accepted too. DISPOSITION: Accepted, Sayre suggested good wording calling in all the specs that are covered. PaceEntriesElement Drowning in -1's. DISPOSITION: Close it. PaceEntryOrder One -1, but overwhelming support otherwise. DISPOSITION: Accepted. PaceExtensionConstruct One -1, 1.5 +1's. DISPOSITION: Not enough support, close it. PaceFeedRecursive Lots of -1's. DISPOSITION: Close it. PaceFeedState Lots of -1's. DISPOSITION: Close it. PaceNoFeedState A few +1's, nothing negative. DISPOSITION: Accepted. PaceFormatSecurity Evenly split +1's and -1's. DISPOSITION: No consensus and we have PaceSecuritySection, close it. PaceHeadless Lots of talk, more -1's than +1's. DISPOSITION: No consensus, close it. PaceIconAndImage One -1, but broad support otherwise. DISPOSITION: Accepted. PaceLangSpecific Not a lot of discussion, but pretty positive. DISPOSITION: Borderline, but accepted. PaceLinkEnclosure A little bit of support, but with reservations. DISPOSITION: A messy Pace and not enough support, close it. PaceLinkRelVia Moderate support, no objections. DISPOSITION: Borderline, but accepted. PaceMultipleImages Lots of -1's. DISPOSITION: Close it. PaceMustBeWellFormed Very little discussion, no unambiguous support. DISPOSITION: Our longest-lived Pace is finally closed. PaceOrderSpecAlphabetically A bit of support, not much talk. DISPOSITION: This is editorial, let the editors run with it. PaceProfile Changed along the way, quite a few +1's but even more -1's. A certain amount of +1 on concept, -1 on syntax which doesn't help. DISPOSITION: No consensus, close it. PaceProfileAttribute No significant support. DISPOSITION: Close it PaceRemoveInfoAndHost Not much discussion, but no opposition. DISPOSITION: Borderline, but accepted. PaceRemoveVersionAttribute Quite a bit of support, quite a bit of grumbling but no loud -1's. DISPOSITION: Borderline, but accepted. PaceRepeatIdInDocument Lots of discussion, more -1's than +1's. DISPOSITION: No consensus, close it. But now we have a problem, in that this removed ambiguity in one direction, just closing it leaves the ambiguity. So the only logical conclusion is that the WG is directing the editors to put language in that explicitly forbids entries with duplicate atom:id in an atom:feed. PaceSecuritySection More support than opposition, but some feeling that the IETF is going to make us do something like this anyhow. DISPOSITION: Borderline, but accepted. PaceTextRules Only one (positive) comment. DISPOSITION: Not enough support, close it. PaceXhtmlNamespaceDiv This is tough. There are some people who are really against this and who aren't moving. On the other hand, there are way more who are in favor. Reviewing the discussion, the contras are saying that this is sloppy and unnecessary and if it solves a problem, that problem really shouldn't be there, but they don't seem to be saying it's actively harmful. But the people in favor are arguing that this will reduce errors and improve interop. Also, the Pace was changed in
Re: Rehashing? Why is link required in entry?
+1 to removing this bit.
[[
4.2 The atom:head Element
...
o atom:head elements MUST contain at least one atom:link element
with a rel attribute value of alternate.
]]
The per-entry link has been dealt with, I suspect the per-feed link
slipped under the net. The rationale is similar.
http://www.intertwingly.net/wiki/pie/AtomPubIssuesList
has
http://www.intertwingly.net/wiki/pie/PaceContentOrLink
Accepted for Incorporation - Incorporated-Format-04
Abstract
Make atom:link required ONLY IF atom:content is not present.
On Fri, 11 Feb 2005 16:40:22 -0500, Norman Walsh [EMAIL PROTECTED] wrote:
A quick skim of the last 1000 messages on this list doesn't reveal
recent discussion. Apologies if the issue's been put to bed and I'm
just being clueless.
I'm building an Atom feed for the changes to norman.walsh.name.
Whether you want to track changes to my blog is open to question, but
a feed of changes to a repository I cared about would definitely be of
interest to me.
Here's an example of what I'm generating now:
entry
titleRevision 20/title
!-- This is a lie. --
link rel=alternate type=text/html href=http://norman.walsh.name//
idhttp://norman.walsh.name/Subversion/R20/id
updated2005-02-11T12:34:51.027481Z/updated
author
namendw/name
/author
summary type=TEXTFixed URI typo/summary
content type=TEXTFixed URI typo
M /2005/02/09/subversion.xml/content
/entry
The problem is that link element. Each entry represents a revision
to the repository and that revision doesn't have any alternate
representation.
The options as I see them:
1. I could lie.
2. I could leave it out and not worry about it.
3. I could be devious and use:
http://norman.walsh.name/atom/subversion.xml#xpointer('/1/2/6')
Though I'd have to use content type=HTML then, I think.
4. Actually go and create a representation and point to it.
5. Persuade the WG to make link optional if there's a content construct
that isn't empty.
I might do 4, just because I want to be compliant and it wouldn't be
that hard, but I would guess that most folks won't do that.
Maybe we've already decided to do 5 and I'm just behind the times.
Otherwise, can I convince the WG to do that? :-)
Be seeing you,
norm
--
Norman Walsh [EMAIL PROTECTED] | I have come to believe that the whole
http://nwalsh.com/| world is an enigma, a harmless enigma
| that is made terrible by our own mad
| attempt to interpret it as though it
| had an underlying truth.--Umberto Eco
--
http://dannyayers.com
Re: type=HTML
On Tue, 08 Feb 2005 15:36:11 +0100, Julian Reschke [EMAIL PROTECTED] wrote: Shouldn't we at least give content producers the hint that producing XHTML content is preferred over HTML? (sorry if I'm opening a can of worms here) Sounds reasonable, but as type=XHTML. Escaping XHMTL seems to be defeating the object somewhat (we should be encouraging XML processing rather than tag soup microparsing). -- http://dannyayers.com
Re: PaceProfile
On Tue, 08 Feb 2005 12:47:51 +, Bill de hÓra [EMAIL PROTECTED] wrote: +1 on the concept. I've seen enough cases in the last week to suggest it's useful. +1 -1 on @profile - use an @rel to hold the content instead. I'm not sure whether atom:feed should get an @rel or whether we should use atom:feed/atom:[EMAIL PROTECTED] Not sure on this - the @profile name might act as a good hint to its purpose. +0, looking forward to some refactoring of the proposals... -- http://dannyayers.com
Re: PaceStopArguingAboutSlidingWindowsAndCurrentStateEnoughAlready
On Tue, 08 Feb 2005 10:40:43 +, Bill de hÓra [EMAIL PROTECTED] wrote: Henry Story wrote: If you just want to stick to syntax, then please leave the pace as it is. Don't try to impose a model through syntax and then argue that people can't argue about the model that you are surreptitiously trying to introduce. Henry, I have no idea what you are talking about. I think all Henry's referring to is the implicit model - only so much is made explicit in the spec. There's the obvious containership semantics of XML, there are also plenty of assumptions being made about server/client architectures. Bits over the wire are useless on their own, when semantics are to be attached to them there is benefit in them being standardised through specs. However even if there was the will to define a model, I can't see it happening in the time frame for Atom 1.0. Getting something in an I-D later for RDF-based interop should benefit the core, even without tight spec coupling. But don't let's kid ourselves what we have right now is much more than a syntax and a model with ArchitectureByImplication [1]. 10/10 for the Pace title, btw ;-) Cheers, Danny. [1] http://c2.com/cgi/wiki?ArchitectureByImplication -- http://dannyayers.com
Re: Thinking ahead: Atom Extension Proposals on the Wiki?
On Wed, 02 Feb 2005 20:27:28 -0500, Sam Ruby [EMAIL PROTECTED] wrote: James Snell wrote: I'm just thinking ahead a bit on this, but I am wondering if it would be possible for those of us interested in proposing non-core extensions to Atom to use the Wiki as the forum for sharing proposals for extensions once the core syntax has been finalized? Go4it. Yep, good idea. I can see a few in the intray: ipaddress/host (for anon posts to Wikis etc); the ENT (Easy News Topics) RSS 2.0 extension is in the process of being revised, and an Atom-compatible syntax is planned; Yahoo's media object extension. A Wiki template would be nice - have you started writing anything up yet, James? Cheers, Danny. -- http://dannyayers.com
Re: tagline - subtitle
+1. Subtitle is less obscure, and as Graham suggests could reasonably encompass tagline. Summary isn't far away, but subtitle and tagline are both more suggestive of the kind of half-a-sentence people use in this position, rather than a paragraph+. On Wed, 2 Feb 2005 15:37:09 +, Graham [EMAIL PROTECTED] wrote: Any chance of renaming atom:tagline to atom:subtitle? The two sample feeds posted today have the taglines ongoing fragmented essay by Tim Bray and WebDAV related news. Aren't taglines meant to be funny or catchy or clever? The relevant definitions from dictionary.com are: tagline: An often repeated phrase associated with an individual, organization, or commercial product; a slogan. subtitle: A secondary, usually explanatory title, as of a literary work. The second seems much broader and more useful, and there's nothing stopping you using a slogan as subtitle. Graham -- http://dannyayers.com
Re: Work Queue Rotation #16
On Mon, 31 Jan 2005 11:45:25 -0800, Tim Bray [EMAIL PROTECTED] wrote: Atom Public Issues List: http://www.intertwingly.net/wiki/pie/AtomPubIssuesList Regarding PaceExtensionConstruct, PaceAttributesNamespace and Henry's RDF-related proposals, these got Catch-22'd by the process a little. The chair wanted actual spec text to enable discussion, but the text as provided (at least for PaceAttributesNamespace) was more aimed at alpha version 0.001 ballpark-finding than providing something voteworthy. I'll try and have something more workqueue-suitable for PaceAttributesNamespaces in the next few days. The other decisions look good to me - they all seem to reflect discussion accurately (although I somehow missed PaceFeedState...). Cheers, Danny. -- http://dannyayers.com
Re: atom:host [was: Comments on format-05]
On Sun, 30 Jan 2005 22:51:21 -0500, Joe Gregorio [EMAIL PROTECTED] wrote: atom:nameAnonymous (from IP: aaa.bbb.ccc.)/atom:name Well yes, and there's always: atom The title of this feed is The Stuff and the first entry it contains is titled Hello World from 1st February, and that has the content ... /atom What did you end up implementing for the Wiki? I've no objection to this being dropped from the core in its current (misleading) form, I think it would probably cause more trouble than it's worth. The use case is nice and clear though - this could make an exccellent extension demo. Cheers, Danny. -- http://dannyayers.com
Re: URI canonicalization
On Tue, 01 Feb 2005 10:07:52 +, Bill de hÓra [EMAIL PROTECTED] wrote: Otherwise, this thread sounds like resources and representations all over with the caveat that entry representations are being sourced from multiple origin servers. It was suggested ages ago that the use of a different URI in id than the one which would usually provide representations of the entry resource might be problematic. There's an extra level of indirection between the identified entry resource and it's representations (which are in fact also representations of *other* resources). There doesn't seem to be any violation of webarch with that per se. But if we decide Cool URIs are to be considered an exception rather than the norm and use workarounds to fit with the half-baked 'permalink' practice then confusion is to be expected. Cheers, Danny. -- http://dannyayers.com
Re: URI canonicalization
Nearly forgot - +1 to including some kind of explanatory note on comparisons, Martin's version looks better than the current text -- http://dannyayers.com
Re: Dereferencing Identity Constructs
I'm a little confused over what's being proposed or counterproposed here - I thought consensus last year was to break the Web Whatever, I do think id URIs should be treated as URIs according to webarch etc - it should be possible to dereference them, assuming that's supported by the scheme. The easiest implementation of a blog feed would be to have the id referring to the resource entry that has a HTML representation in the blog. It seems perverse to build a whole new system of Web data reference around permalinks and assuming unCool URIs. Cheers, Danny. On Tue, 1 Feb 2005 17:59:51 +0100, Henry Story [EMAIL PROTECTED] wrote: Ahhh! Here I make the mistake again. The id relation, relating an Entry and a Identity Construct is functional, not inverse functional. Hence an Entry can only have one id relation to a URI of type identity construct. But there is a way out of this: if an entry has a number of id relations, then one is forced to conclude that those identity constructs have the relation same as. So if one had entry titleAtom Robots run Amok/title idhttp://bblfish.net/blog//id idtag://bblfish.net/eternalid/for/that/story/id ... /entry Then one would be forced to conclude that http://bblfish.net/blog/ rdf:sameAs tag://bblfish.net/eternalid/for/that/story (wink to advanced rdfers: is that ok?) for rdf newbies with primary mathematics background consider the function f(x) = x * 25 so f(0) = 0 f(1) = 25 f(2) = 50 etc. if we are told that f(a) = 100 and f(a) = 2*50 then we can conclude that 100 == 2*50 Henry Story On 31 Jan 2005, at 16:25, Henry Story wrote: One way to get people to have their cake and eat it too, may be to allow multiple id tags. Since an id is an inverse functional relationship between an Entry a Resource this should not cause any trouble. In any case there will never be any way you can limit the number of names a thing has. Henry Story -- http://dannyayers.com
Re: Proof-of-concept RDF mapping for Atom
On Sun, 30 Jan 2005 16:05:57 +, Bill de hÓra [EMAIL PROTECTED] wrote: Robert Sayre wrote: I think the mapping should be normatively defined w/ XSLT. +1. I have no problem with defining the mapping in XSLT. Executable specs are a wonderful idea. +1. There still quite a margin for error but XSLT could very neatly provide something deterministic, and ties in nicely with GRDDL. The mapping won't really be complete without an RDF/OWL schema (and probably not even then, given some of the Atom constructs), I would expect that to form part of the I-D (or however it's presented). Another benefit of XSLT is that it should be pretty easy to hook onto a Atom/XML validator to pass to the W3C RDF validator. Cheers, Danny. -- http://dannyayers.com
Re: Proof-of-concept RDF mapping for Atom
On Fri, 28 Jan 2005 21:27:11 +, David Powell I've put together an XSLT stylesheet to map Atom to RDF/XML. It is just as a proof of concept to see if it is possible. I think it handles everything except for xml:lang - I'm not sure what's happening with xml:lang at the moment - but it should be possible to add it in a similar way to xml:base. Marvellous! I don't think using an XSLT processor followed by an RDF/XML parser would be much fun in practise - a SAX based convertor would be much simpler. Hmm, that's actually quite an interesting question... The RDF vocabulary was just constructed ad-hoc - like I said, it is just a proof of concept. It uses a separate namespace to Atom and defines some new terms, which solves any problems with non-unique attributes. That makes sense. Hopefully it should be possible to narrow down the terms in a way that they can all coexist in the Atom namespace. One question - do you have a permanent URI for this? Cheers, Danny. -- http://dannyayers.com
Re: PaceAttributesNamespace is *not* about syntax!
On Wed, 26 Jan 2005 21:39:23 -0500, Sam Ruby [EMAIL PROTECTED] wrote: PaceAttributeNamespace does not do that. All it says is is that a given namespace may be used. For what purpose such a statement is made is entirely unclear. Ok, maybe a little more explanation is needed in the Pace. The purpose is to provide global names to the relations expressed by the attributes. Global naming leads to global network effects. http://www.w3.org/TR/2004/REC-webarch-20041215/#identification Cheers, Danny. -- http://dannyayers.com
Re: Difference of TEXT and XHTML?
I only noticed this thread after looking at the same material through RDF-tinted spectacles. A question for the schema mavens: is there *any* clear way of describing the difference between the three content types (TEXT/HTML/XHTML) in a machine readable fashion? In the Rosy-tinted Description Framework, if the type could be fully expressed using XML Schema datatypes, the Atom content element could map nicely onto a XSD-datatyped literal. Problem is I couldn't see any obvious way of distinguishing HTML from TEXT, as the former would be escaped anyway. So in effect for RDF I think the content would have to appear as a literal, with the type as a kind of annotation, the easiest RDF/XML version being something like: atom:contentConstruct atom:contentyodel-ay-ey-oo/atom:content atom:datatypeTEXT/atom:datatype /atom:contentConstruct Cheers, Danny. On Thu, 27 Jan 2005 14:48:44 +, Graham [EMAIL PROTECTED] wrote: On 27 Jan 2005, at 1:34 pm, Sam Ruby wrote: http://www.intertwingly.net/wiki/pie/PaceTypeTextRedundant There are cases where explicit is better than implicit. Yes. It's more a psychological rather than a technical difference, but I think it's important (it's like the difference between ASCII and UTF-8). -1 on the pace. Graham (PS Are line breaks in Text mode honored?) -- http://dannyayers.com
Re: PaceAttributesNamespace is *not* about syntax!
On Thu, 27 Jan 2005 20:49:12 +, Bill de hÓra [EMAIL PROTECTED] wrote: Danny Ayers wrote: Yes and no - there is demand for this kind of thing, is the RSS 1.0 community the same as the RDF community? There's a lot of additions around there... Whatever, even with RSS 2.0 there's Easy News Topics and all the stuff associated with media (enclosures + Yahoo's extensions) as good examples. Is the RSS1.0 community relevant, given RSS1.1? I'm sincere in asking this. Dunno really. There are an awful lot of RSS 1.0 feeds out there - you've got one, I've got one. If rss-dev give the green light to 1.1, I'll probably changeover before long, though the extensions (FOAF, Geo) I've got in place aren't likely to change. My concern there is with extension development outside of the RDF community. Without some uniform interpretation of the attributes outside of the context of an Atom document, there's scope for unwanted interactions. Assigning the things global names (URIs), even if they aren't explicitly expressed in Atom documents seems a low cost solution. Does this help? Yes, but I think it can be dealt with as outlined above, unless I'm missing something. Non-RDF extensions. As I've said, I'm not seeing the demand for uniform evaluation outside an RDF context. Outside of the [insert Brayism about architects], demand for uniformity is generally thin on the ground around syndication (guids ring a bell?). But that doesn't reduce its benefits, usually uniformity leads to a net cost reduction, don't you reckon? Standards and all that? Cheers, Danny. -- http://dannyayers.com
Re: PaceAttributesNamespace status
On Wed, 26 Jan 2005 01:20:58 +, David Powell [EMAIL PROTECTED] wrote: PaceAttributesNamespace I'm -1 on this. It seems to be authorising a RDF users to do a transform on Atom Syntax in order to make it more RDF/XML-like. That's really orthogonal from the intention. If RDF users have to transform the content in order to interpret it as RDF/XML (which they do), then they might as well transform it to a decent RDF model which properly models the entities and properties involved in the feed. We don't need the format spec to authorize RDF users to do this - they can just do it. True. But that decent RDF model will presumably be based on the model implicit in the Atom spec. But there are points which can't be carried from the spec as it stands into the world of resources at large - the unqualified attributes. I don't think that tweaking an Atom document and interpreting it as RDF/XML is going to produce a sensible RDF model. That isn't really the intention, although there's no reason to make the transformation any more complicated than it needs to be. There are also a number of technical problems: * The attribute namespace prefixing problem solved by this Pace * atom:author defaulting won't be modelled sensibly * The xml:lang and xml:base context won't be preserved by Text constructs and Extensions if they are modelled as RDF XML Literals.[1] * parseType=Resource / parseType=Literal needs to be assumed in certain places. Only the first is covered by this Pace. If we try to solve all of these problems, then we are going to have to do a fairly complicated transformation that needs to be applied to produce a what could end up a quirky sub-optimal model. This is extrapolating a lot way from the proposal. I'd rather us make sure that we have designed the format spec well enough that it has a clear model for core elements and extensions. Yes, exactly. Then the RDFers can come up with a clear well-designed RDF vocabulary for Atom and a mapping from Atom format to RDF (via XSLT?). There is a clear mapping of construct *names* from Atom to the RDF world (the element names have URIs), but the unprefixed attributes don't have URIs. I've just posted this as an informal proposal on the Wiki suggesting that we let an RDF mapping should be defined outside of the format specification, and that we should avoid making this impossible: http://intertwingly.net/wiki/pie/MinimalRdfProposal Interpreting Atom syntax as RDF/XML is not possible without applying transformations. I don't care about Atom syntax as RDF/XML per se, what I'm interested in is Atom as RDF. Atom should define a consistent model for its core elements. Exactly. What it currently lacks is unambiguous names for the attributes outside of document instances. Cheers, Danny. -- http://dannyayers.com
PaceAttributesNamespace is *not* about syntax!
I've added the following note to the Pace: A lot of the critical response to this Pace has been based on the assumption that it is about changes to the Atom syntax. Nothing could be farther from the truth. Within Atom format it will remain mandatory that documents are produced with no-namespace attributes. This Pace is about the model. Resources on the Web are generally given URIs. With RDF, it has been found useful to also assign URIs to relations, so they too are uniformly are uniquely defined. As it stands, most of the constructs and relations within Atom already have URIs - the element names are namespace-qualified. This isn't the case for the attributes. By saying that the no-namespace attributes can be interpreted as having names in the Atom namespace gives them URIs. As well as simplifying the RDF model the approach described in this Pace should also be useful for reusing Atom attributes in extensions. http://intertwingly.net/wiki/pie/PaceAttributesNamespace Cheers, Danny. -- http://dannyayers.com
Re: PaceIRI status
+1 on PaceIRI I'm a little hesitant on this because I'm not familiar with the issues, but it's something we'll probably all have to broach sometime soon. Martin seems to know what he's talking about ;-) On Wed, 26 Jan 2005 08:54:51 +0100, Julian Reschke [EMAIL PROTECTED] wrote: Martin Duerst wrote: ... Bjoern was making a vaild, but fine, point: Because we decided to refer to RFC2396bis, rather than to RFC2396, we already have bought into the fact that RFC2396bis allows percent-encoded domain names, and thus essentially requires IDN support. (apart from the basic fact that no resolver is required to resolve all URIs or IRIs) ... OK, thanks for making me aware of this subtle change. ... Regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -- http://dannyayers.com
Re: PaceExtensionConstruct status
On Tue, 25 Jan 2005 02:10:28 +, David Powell [EMAIL PROTECTED] wrote: +1 (allowing room for tweaks) I'll try to post my suggested RDF road-map tomorrow - basically, I'd like to see: * an Atom syntax - RDF mapping defined in a separate I-D. * no changes to the Atom syntax for the sake of RDF. * a model that maps properly onto the core Atom concepts without getting tangled up in the Atom syntax. Yep. Expect +1s from me for anything along these lines. An appendix covering RDF compatibility mapping has been suggested. I would expect that to be brief (and wouldn't object to it being solely informative), with the bulk of the material appearing in the separate ID. But right now I'd say the challenge is to get the third item above sorted. I believe Henry's got most of an RDF/OWL model worked out - perhaps he could be persuaded to post it to the Wiki for nitpicking..? Correct me if I'm wrong - the tricky bit relating to content datatypes still needs figuring out, along with a couple of inconsistencies/weird structures within Atom. Cheers, Danny. -- http://dannyayers.com
Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)
On Mon, 24 Jan 2005 21:35:37 -0500, Sam Ruby [EMAIL PROTECTED] wrote: Danny Ayers wrote: One thing I'm not sure about - where it currently says Atom processors, perhaps that would be better as merely Atom consumers. For the reasons Sam gave, we don't really want extra variability in what's being produced, but this still would still allow RDF-like consumers to interpret the feed as an RDF-like language. Does that make sense, or is there a case I'm missing here? I'm still struggling to understand what this is for. So, let me ramble for a few minutes... Assuming that there will be an XSLT which maps Atom to RDF, such an XSLT will have to map all unnamespaced attributes into something with a namespace. The namespace of the element is a reasonable choice. I'm not sure whether it'll be a good strategy to allow no-namespace attributes in extensions - extension-creators may want to use terms from within the Atom namespace in other elements (although I guess they could use the qualified versions), and it also feels like it might complicate handling (if this wasn't allowed then 'namespace of element' would still be the rule, except that namespace would always be Atom's). I realise XSLT/GRDDL is the obvious target for this stuff, but I worry a little about thinking in terms of a particular processing model. It would be nice for example if the DTD defaults could be used as a simple Atom = RDF/XML transformation, although I doubt that's possible given the namespaced attributes situation (no-namespace attributes were deprecated in RDF/XML, not sure whether they ever got banned outright). I'm a bit concerned about precedence rules (what happens if there is an href attribute *AND* an atom:href attribute?). What makes most sense here is for a prohibition disallowing such in any exension. I would support such a rule. Yep, that makes sense. Finally, I'm a bit concerned about round tripping - i.e., producing valid feeds from an RDF triple store. Given that an unnamespaced attribute and a namespaced attribute are two different things - how can a valid feed be produced? Some fairly hardwired coding will be required to constrain the syntax down to RDF/XML of the right shape anyway, I'm assuming it would only be a tad more application code to change the attribute namespaces. It would be a little easier if Atom attributes were always namespace-qualifie (it would be a lot simpler if Atom were RDF/XML...). Cheers, Danny. -- http://dannyayers.com
Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)
On Tue, 25 Jan 2005 04:33:35 +0100, Bjoern Hoehrmann [EMAIL PROTECTED] wrote:
* Danny Ayers wrote:
To be inserted:
{{{
Section 2. Atom Documents
Atom processors MAY interpret unprefixed attribute names as their
namespace-qualified equivalents.
If they do, then all Atom attribute names MUST appear in the Atom namespace.
}}}
This does not make much sense to me, it is either not possible to write
a test case for the first requirement in which case this would be an im-
plementation detail which is out of scope of the specification, or it is
possible to write such a test case in which case this would render Atom
inconsistent with a broad range of XML technologies, e.g., for
atom:foo bar=baz /
Sorry, swap in the word 'consumer'. Straight XML applications will see
that exactly as written, languages that require disambiguation of
'bar' will read it as 'atom:bar'
A test case would be an RDF processor seeing the triples:
_:fooinstance rdf:type atom:foo .
_:fooinstance atom:bar baz .
(assuming atom:foo was a class)
Cheers,
Danny.
--
http://dannyayers.com
Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)
On Tue, 25 Jan 2005 12:22:24 +0100, Bjoern Hoehrmann [EMAIL PROTECTED] wrote: If this implementation detail is exposed to the user, it would seem reasonable to consider such a software a Atom-to-something-else con- verter; you would thus seem to propose the introduction of conformance requirements for Atom conversion programs into the specification. No? Not necessarily - although I take your point, it does look very application oriented and probably impossible to test within the scope of core Atom. But because it is defining the meaning of terms in the Atom namespace (atom:type will be equivalent to type) I believe this information should go in the normative part of the core spec. Cheers, Danny. -- http://dannyayers.com
PaceAttributesNamespace refactored
I have withdrawn the previous suggestion and replaced it with the text suggested by Antone. Further adjustments/refinements welcome. The key idea is anchor the attribute names in the Atom namespace, reducing ambiguity. I would expect the reduction of ambiguity is desirable in a spec. This should be useful in practice when Atom is used alongside any language where terms need to be unambiguously qualified, such as RDF. It should also simplify the reuse of core attributes in extensions (again, through ambiguity reduction). Cheers, Danny. -- http://dannyayers.com
Re: AtomOWL AtomAsRDF
On Mon, 17 Jan 2005 23:38:50 +0100, Henry Story [EMAIL PROTECTED] wrote: Take for example the following extension proposed recently entry idtag://sometag/id geo:x10.1/geo:x geo:y57.3/geo:y ... /entry this implies the following rdf graph _e -entry- _E |-id--tag://sometag |-geo:x-10.1 |-geo:y-57.3 which presumably would mean that _E had to be both an Entry and a geographical location, ...or an entry *with* a geographic location (or something completely different). which is a very unintuitive concept, and very likely *not* what the extension author intended. It would for example meant that this object would be a different object if it had a different id. What he probably intended was either - That the author was at some particular location, in which case he should probably have added attributes to the author object, through some foaf ontology predicate. - Or that some event the Entry is about was at some particular location. In which case this should have gone into the content /content space by using an event ontology. Maybe, but there's always the trade-off between accuracy of modelling and difficulty of handling the stuff. There's really nothing to stop the resource identified in id being a geological event with a geographic location as well as something with a representation in the content of an entry in an Atom feed. The indirection can be reduced with the data expressing what the entry is, rather than what it is about. This example probably works better than most in human terms, as the entry could be an entry in an event log, though you could end up with the author of the feed entry being the creator of the earthquake... Cheers, Danny. -- http://dannyayers.com
Re: Feed, know thyself?
On Fri, 14 Jan 2005 15:52:58 -0500, Robert Sayre [EMAIL PROTECTED] wrote: Danny Ayers wrote: Thing is, with the spec as it currently stands, we don't have a link from the feed that can be guarenteed to point to the feed URI itself. That's not a very robust way to accomplish the goal. People tend to use cp without thinking about these things. Do they? I've done HTTP redirects often enough (had to yesterday, coincidentally) but don't recall ever having to do anything that would break a source reference. The browser vendors will deal with it eventually (Safari 2.0 does...) and/or we'll get a playlist type thing. That's the only way it will work reliably. Maybe, but right now the leading browser doesn't deal with it, it's not clear they even have any motivation to. Seems to me like making a source-URI reference a SHOULD would help solve an immediate problem, irrespective of the hypothetical problem of copying. Is a Pace needed? (Where is the time???) Cheers, Danny. -- http://dannyayers.com
Re: Feed, know thyself?
On Sat, 15 Jan 2005 08:37:47 -0800, Tim Bray [EMAIL PROTECTED] wrote: On Jan 15, 2005, at 1:05 AM, Danny Ayers wrote: Seems to me like making a source-URI reference a SHOULD would help solve an immediate problem, irrespective of the hypothetical problem of copying. I see no downside. There are going to be scenarios where it's not reliable, but there are going to be lots where it's useful. Is a Pace needed? Yes. -Tim [expletive deleted]! Ok, I'll try and sort it tomorrow. I'm sure extensibility is in good hands... Cheers, Danny. -- http://dannyayers.com
Re: Feed, know thyself?
On Sat, 15 Jan 2005 15:15:46 -0500, Robert Sayre [EMAIL PROTECTED] wrote: No, this is already possible with RSS 1.0. Really? How is it done? My apologies, the RSS 1.0 spec actually says the rss:channel resource is ...either the URL of the homepage being described or a URL where the RSS file can be found. -- http://dannyayers.com
Feed, know thyself?
I was just in the middle of putting the world to rights regarding feed discovery/subscription from browsers [1] when something occurred to me. Correct me if I'm wrong, but isn't one of the solutions for this to serve the feed with the Atom mime type, which will trigger an appropriate handler in the browser? If I remember correctly from previous discussions, there is a little snag with most browsers only passing the data, not the source URI. Thing is, with the spec as it currently stands, we don't have a link from the feed that can be guarenteed to point to the feed URI itself. Having the handler go back to a HTML page to do autodiscovery seems a little roundabout. Relevant spec bit pasted below. Thoughts? Cheers, Danny. 4.2.2 atom:link Element The atom:link element is a Link construct that conveys a URI associated with the feed. The nature of the relationship is determined by the construct's rel attribute. atom:head elements MUST contain at least one atom:link element with a rel attribute value of alternate. atom:head elements MUST NOT contain more than one atom:link element with a rel attribute value of alternate that has the same type attribute value. [1] http://danja.typepad.com/uncooked/2005/01/life_the_univer.html -- http://dannyayers.com
Re: Posted PaceExtensionConstruct
On Thu, 13 Jan 2005 08:45:07 +, David Powell [EMAIL PROTECTED] wrote: I very much like the general approach of this Pace, I reckon it's very close to what's needed. If there is some way to lose atom:notation without introducing ambiguity it would be better (if something is needed, what about atom:type as used on content - might that be a suitable replacement?) My feeling is that ideally it should be possible to deterministically transform Atom+extensions into an abstract model based on entities and relationships. Whether the target model is traditional E-R, UML, RDF, Topic Maps or whatever doesn't matter. From there it would be easy to see how specific profiles could be developed, without impacting the core - so Henry's RDF/OWL description of Atom could appear in an I-D as the RDF Profile of Atom. I think this could potentially be better than what's found with most profiling, not requiring additional constraints. There would be a guarantee that the output of *the* Atom2RDF XSLT would always be valid RDF/XML if the input was valid Atom(+extensions). (It would be nice later to have XSLT for Atom2UML, whatever Rational etc use - XMI? - that could be used to automatically create class libraries for arbitrary extensions). Cheers, Danny. -- http://dannyayers.com
Re: PaceIRI
On Tue, 11 Jan 2005 16:50:56 +0900, Martin Duerst [EMAIL PROTECTED] wrote: http://www.intertwingly.net/wiki/pie/PaceIRI I like it a lot in principle, my only concern is the dependency on an IDN library (nicely put together Pace, btw). As noted this might be a problem on small devices, but I would suspect that a proportion of big-device implementors might be tempted to skip this step (if they're anything like me, largely through ignorance of IRIs/IDNs in general). Is there any way of reducing the impact here? Any deployment experience from other application domains that can be drawn on? Cheers, Danny. -- http://dannyayers.com
Re: Regarding Graphs
On Sun, 9 Jan 2005 15:20:56 -0800, Roy T. Fielding [EMAIL PROTECTED] wrote: For example: feed xmlns... head link href=http://example.org/feed/ ... /head entry idhttp://example.org/entry/id link rel=related href=http://example.org/feed; / ... /entry /feed If resources are view as nodes, then http://example.org/feed has two parents. The containment tree is violated. Nonsense. The containment tree tells us what the tail of the link is, not the target of those links. The information is going to have far more relationships just by virtue of the content text, and thus the information will be a graph even if the relations are not made explicit via links. Well yes, that was really what I was trying to say, that there are more relationships than those expressed by the tree. Their containment is only a very small subset of those relationships and cannot be violated by the mere presence of other types of links. If you restrict the set of entities and relationships under discussion to those directly involved in containment relationships, then sure, containment will not be violated. The reason this topic came up was because people wanted to know how the format is extensible given the implicit relationship between feed, entry, and entry elements. Containment is the only answer needed because all other relationships are explicitly targeted by a URI. Other relationships can be targetted by a URI, and this with containment can be enough to describe all the relationships needed. But my original point was that it wasn't being made explicit. Personally, what I would change in the format is elimination of head and make feed a recursive element. Then there would be no doubt as to the hierarchical relations and feed vacuums can compose multiple feeds to their heart's delight without changing the entries at all. I think this approach was suggested fairly early on, I'm not sure why it didn't make it through, possibly the argument that flatter is simpler (for non-Functional developers). The (recursive) nesting approach can certainly work well, I've seen striped RDF/XML that looks like this, even the overstretched OPML (sometimes) works because of it. I'm not sure how you'd deal with multiple occurrences of the same entry/feed in different layers. I suppose they could be referred to through their URIs. Cheers, Danny. -- http://dannyayers.com
Re: PaceFeedRecursive
On Sun, 9 Jan 2005 16:36:04 -0800, Roy T. Fielding [EMAIL PROTECTED] wrote: http://www.intertwingly.net/wiki/pie/PaceFeedRecursive I like it, but seem to remember a similar proposal being rejected - anyone..? This approach should be pretty straightforward to program against, and what's more should offer easy processing/data access through XSLT/XQuery and simple mapping to RDF (essentially using striped RDF/XML). The only issue that springs to mind is that a feed could end up with a huge amount of redundant chars if the same feeds/entries appeared multiple times in different branches of the hierarchy. A simple mechanism for substituting a feed/entry with its URI might do, or alternately an in-document #id kind of cross reference to the first occurence of the feed entry. Cheers, Danny. -- http://dannyayers.com
Re: PaceFeedRecursive
On Mon, 10 Jan 2005 11:49:35 -0500, Bob Wyman [EMAIL PROTECTED] wrote: Roy T. Fielding wrote: a proposal on making the feed element recursive The primary arguments against Feed of Feeds have been (my apologies if I forgot some...) Thanks Bob. IMHO there are pretty strong counter-arguments to 1-5, but this is trickier: 6. Concern that Feed of Feeds really doesn't buy you much that Head In Entry doesn't already provide in the normal case. Ok, I don't think there is any benefit in the normal case (feed ::= meta, (meta, content)*), but the recursive nesting method makes it possible to convey information about relationships between feeds. Which begs the questions: How useful are the semantics of one feed containing another? How desirable is it to convey such information in Atom format? Cheers, Danny. -- http://dannyayers.com
Regarding Graphs
There were a couple of points made in recent discussions that might have been misleading. One was that Atom is a tree. The XML may use that structure, and in it's simplest form the information being represented may be tree-shaped, but that isn't necessary the case. For example: feed xmlns... head link href=http://example.org/feed/ ... /head entry idhttp://example.org/entry/id link rel=related href=http://example.org/feed; / ... /entry /feed If resources are view as nodes, then http://example.org/feed has two parents. The containment tree is violated. From one or two other recent posts a casual bystander might have concluded that it is necessary to know graph theory to use RDF. This isn't really the case. A similar suggestion has been used in the past [1,2,3] to imply RDF is harder than it actually is. In that sense, it's completely unfounded. All you need to know is that RDF data can be visualized as a node and arc (edge) graph. The arcs have a direction, i.e. it's a directed graph. The same information can be represented either as a circle arrow kind of diagram, as a list of statements (triples) or in one of the serialization formats like RDF/XML or the more human-friendly Turtle. Viewed as a list of statements, the information in the Atom snippet above could be expressed something like: feed hasHref http://example.org/feed feed hasChild entry entry hasID http://example.org/entry entry hasRelated http://example.org/feed Anyone working on the Web is dealing with graphs all the time. There's the Web itself, with pages as nodes and links as arcs. Gopher might have evolved into the World Wide Tree, but didn't. Trees are a constrained subset of graphs, so they can be assimilated in a hugely interconnected environment like the Web (resistance is futile!). Anyone programming is likely to be using considerably more complex graphs than what's usually found in RDF. The relationships between entities in, say, the Java class libraries can get very twisty. (You can use similar visualization, using something like UML). This isn't to suggest that the containment tree of XML isn't useful, far from it. It's a very good fit for most documents we have to deal with, and a considerable amount of data. Other data can be more table-shaped, which can be done in XML but the syntax starts to look a little strained. But many real-world data structures (like the Web) don't fall neatly into trees or tables, and the more general graph can be useful. XML can be used effectively for serialization formats, pretty much irrespective of the data structure. But the syntax may get ugly if the data model is too far removed from Tree. Generally the graph data structure is our friend, and should be welcomed with open arms (or angle brackets). Cheers, Danny. [1] http://static.userland.com/userLandDiscussArchive/msg007482.html [2] http://www.xent.com/aug00/0371.html [3] http://archive.scripting.com/2004/07/16 -- http://dannyayers.com
Re: Regarding Graphs
On Sun, 9 Jan 2005 10:59:01 -0800, S. Mike Dierken [EMAIL PROTECTED] wrote: feed xmlns... head link href=http://example.org/feed/ ... /head entry idhttp://example.org/entry/id link rel=related href=http://example.org/feed; / ... /entry /feed If resources are view as nodes, then http://example.org/feed has two parents. The containment tree is violated. I'm pretty sure the discussion was related to the content of a single XML document instance, rather than to resources distributed across a network. Once a piece of software traverses outside of an XML document instance, it is no longer containment. How about something like: feed xmlns... ... entry idhttp://example.org/entryA/id link rel=next href=http://example.org/entryB; / ... /entry entry idhttp://example.org/entryB/id link rel=previous href=http://example.org/entryA; / ... /entry /feed Cheers, Danny. -- http://dannyayers.com
Re: RSS extensibility
On Fri, 7 Jan 2005 16:39:41 -0700, Antone Roundy [EMAIL PROTECTED] wrote: On Friday, January 7, 2005, at 03:53 PM, Danny Ayers wrote: On Fri, 7 Jan 2005 14:21:49 -0700, Antone Roundy [EMAIL PROTECTED] wrote: Could you give an example of something useful that a real world application would be enabled to do? Off the top of my head, how about categorizing entries by their properties. I don't understand. Could I get some example XML, and if the XML doesn't make it obvious, an explanation of how RDF makes this possible where it's not possible lacking RDF? Say your system is aggregating material from two sensors, and you get the following, one from each: entry idhttp://123/id date2005-02-02/date geo:x10.1/geo:x geo:y57.3/geo:y /entry entry idhttp://123/id date2005-02-03/date seismo:magnitude7/seismo:magnitude /entry It isn't clear how these should be merged - does the entry with the later date replace the earlier one? The (presumably) desired behaviour is for the geo+seismo properties all to appear as elements under (properties of) the entry. Mapping syntax to a model can help decide what to do *in the general case* rather than per-extension. As it happens, RSS/RDF would only go part of the way with something like this - you'd get the desired merged entry, but with two dates. But being able to mix extensions in a predictable fashion is generally nice to have. Last time I looked my own RSS 1.0 feed was using terms from 9 namespaces (mostly through the FOAF output plugin). I could merge with lots of other peoples RSS 1.0 feeds and be sure all the same information would still be available. If it wasn't mapped to a common model (through the structure) I wouldn't even know how to merge. Again, I don't understand. When you talk of merging feeds, do you mean making a feed out of entries from separate feeds (but where the entries themselves are not altered), or merging the entries themselves, where sometimes the feeds contain different instances of the same entries, resulting in entries containing more data than exists in any one feed? Either way, what information might become unavailable in the process? Maybe once I understand the foregoing, I'll also understand mapped to a common model (through the structure). There is a predictable way of being able to combine *any* two RDF/XML documents, whatever vocabularies are used. XML alone doesn't provide this. It's also one less job (per extension) for every single developer that wishes to support extensions. This particular part of their code would only have to be written once. Off the top of my head, I can't imagine how this would impact the amount of code required in an application. Could you elaborate? Ok, say x,y come from one extension (geo) and magnitude another (seismo). The client receives something like this: entry geo:x10.1/geo:x geo:y57.3/geo:y seismo:magnitude7/seismo:magnitude /entry a bit of code could pick these values up with characters[] in SAX or a text node in DOM or whatever XOM sees, but the thing is both geo and seismo are following the same structure but if geo and seismo did things a little differently: entry geo:coords x=10.1 y=57.3 / e:magnitude7/e:magnitude /entry a bit of code could pick the magnitude value up as before, but the coords would need different handling - SAX would have to go poking in attributes, DOM would need a getAttribute(), XOM would - ok, I've no idea, but I expect something different. Let me see if I've got this right: you're saying that by standardizing on putting data in element content vs. in attributes, the code would only have to support getting values from element content, and not have to bother with getting attributes? Having typed that sentence, it seems I must be missing something, because the following pseudocode snippets seem only trivially different to me: geox = GetElementContent(/geo:x); geoy = GetElementContent(/geo:y); magnitude = GetElementContent(/seismo:magnitude); geox = GetAttribute(/geo:coords/@x); geox = GetAttribute(/geo:coords/@y); magnitude = GetElementContent(/seismo:magnitude); Yes, trivially different, two extra lines of code. Potentially for every developer, for every extension. I'm assuming the client knows something about the geo and seismo extensions--otherwise, I can't imagine what the client would be doing with the extension elements anyway (beyond ignoring it, storing it in an unknown extension table, or passing it through to some other application). The 'what to do with unknown extensions' question is something that makes a lot more sense if you have commited to the full RDF model. For example, your system might have a piece of data stored: entry ... xxx:wibbleJohn Smith/xxx:wibble /entry You might later pick up the statement: xxx:wibble owl:sameAs rdf:resource=http://purl.org/atom/ns#contributor
Re: RSS extensibility
On Sat, 8 Jan 2005 12:00:19 +, David Powell [EMAIL PROTECTED] wrote: Its a tradeoff between flexibility and complexity. Indeed. There was recently some coverage on-list about using a richer model (in RDF), specifically to preserve provenance. Cheers, Danny. -- http://dannyayers.com
Re: RSS extensibility
On Sat, 8 Jan 2005 13:48:47 -0800, Roy T. Fielding [EMAIL PROTECTED] wrote: On Jan 8, 2005, at 2:21 AM, Danny Ayers wrote: Perhaps I wasn't clear enough. XML has containment. Individual specifications may assign it semantics. RDF/XML assigns it semantics corresponding to the RDF model. Without either the individual specification's definition, or a generalised interpretation like RDF/XML's all you have is syntax featuring containment. No, you were clear, it was just that your statement is false. Element containment is a semantic that almost all XML data formats obey. In fact, the only one I know of that doesn't is RDF/XML. No other format needs to assign those semantics to XML. But XML containment can only express tree structures. To express graph structures, the containment must somehow be violated. RDF is a graph. And Atom feed is a tree. If we try to express tree structures with a graph language, we create complexity that would not exist with a tree language because a tree already has constraints built-in. The extra constraints that RDF needs in order to dig itself out of its own hole are not necessary for languages that avoid the hole in the first place. I do hope that folks understand that the relationship should be obvious to anyone who does not work in a language that is as perversely non-mark-up as RDF/XML. Well there you have it - it is possible to design XML languages that are perverse. So we can't rely on everyone following the 'obvious' relationship pattern. Making it explicit should help prevent misinterpretation. On the contrary, we can safely ignore languages that are perverse in their use of XML because those languages will have to define their own islands of semantics which are self-contained and irrelevant to their surroundings. Other languages do not have to understand the non-containment semantics of rdf:Description because those semantics are defined by RDF/XML regardless of what other language it may be embedded within. Earlier you said: [[ While I don't see any reason not to make XML's mark-up relations explicit in the specification, I do hope that folks understand that the relationship should be obvious to anyone who does not work in a language that is as perversely non-mark-up as RDF/XML. ]] While I disagree with some of the other points you have made (probably none of the facts, more the general focus), I believe the first part of this sentence is the issue that most directly affects Atom, and on that I agree. Cheers, Danny. -- http://dannyayers.com
Re: Atom extensibility, RDF, and GRDDL
On Sun, 09 Jan 2005 00:18:37 +, Bill de hÓra [EMAIL PROTECTED] wrote: Look, the point is this. Those arguing from the RDF side of the house do [not] mean what you mean by extensible. Furthermore, what is meant there by extensible hasn't been demonstrated (in my mind) as a requirement for Atom. Thus, in some respects we're having a pointless discussion. One side or the other is going to have to give up possession of the term extensible, or we're going to continue to watch people talk past each other. Once you appreciate that we are talking about two different things, execution of the work in hand will become simpler. I'd be more than happy to use a different term for the XML-extensibility-like thing which isn't modularity or robustness but closer to the dictionary definition. Extendibility perhaps? Cheers, Danny. -- http://dannyayers.com
Re: RSS extensibility
On Fri, 7 Jan 2005 14:21:49 -0700, Antone Roundy [EMAIL PROTECTED] wrote: Could you give an example of something useful that a real world application would be enabled to do? Off the top of my head, how about categorizing entries by their properties. But being able to mix extensions in a predictable fashion is generally nice to have. Last time I looked my own RSS 1.0 feed was using terms from 9 namespaces (mostly through the FOAF output plugin). I could merge with lots of other peoples RSS 1.0 feeds and be sure all the same information would still be available. If it wasn't mapped to a common model (through the structure) I wouldn't even know how to merge. Ok, now what if the Atom spec said that all child elements of entry are to be considered to be characteristics of that entry, with the value of those characteristics being given by the content of the child. Just for clarification, would that preclude things like the following, where the child element of entry has child elements? entry ... ext:image ext:urlhttp://www.x.com/img.jpeg/ext:url ext:height30/ext:height ext:width40/ext:width /ext:image /entry I would expect this to be possible, but the details need to be worked out (i.e. does the parent-child relationship thing go all the way down? - I'd expect not). It's also one less job (per extension) for every single developer that wishes to support extensions. This particular part of their code would only have to be written once. Off the top of my head, I can't imagine how this would impact the amount of code required in an application. Could you elaborate? Ok, say x,y come from one extension (geo) and magnitude another (seismo). The client receives something like this: entry geo:x10.1/geo:x geo:y57.3/geo:y seismo:magnitude7/seismo:magnitude /entry a bit of code could pick these values up with characters[] in SAX or a text node in DOM or whatever XOM sees, but the thing is both geo and seismo are following the same structure but if geo and seismo did things a little differently: entry geo:coords x=10.1 y=57.3 / e:magnitude7/e:magnitude /entry a bit of code could pick the magnitude value up as before, but the coords would need different handling - SAX would have to go poking in attributes, DOM would need a getAttribute(), XOM would - ok, I've no idea, but I expect something different. Cheers, Danny. -- http://dannyayers.com
Re: Role of RSS in Science Publishing
On Thu, 16 Dec 2004 16:07:11 +, Graham [EMAIL PROTECTED] wrote: On 16 Dec 2004, at 1:53 pm, Danny Ayers wrote: What if they receive multiple, non-identical versions of the same entry from different sources? Admittedly there isn't a conflict resolution defined for core RSS 1.0 components, e.g. where only a single value is mandated, but for extensions (which we are talking about here) the RDF model is clear (there is no conflict). Well you have 2 (or 3) choices: 1. Use the newer entry 2. a) Mix all the elements in one entry container or b) as a), but remove duplicately named elements. Option 1 requires app-specific knowledge, which RDF can't help you with. Neither 2a or 2b will necessarily produce valid results, but again, I'm not aware of a feature in RDF that will help. What helps in RDF is that according to the model, there is no such ambiguity at the common language level - there are no choices. This provides independence, orthogonality between the message-passing and the application-level interpretation. For example, say the following came from sourceA: item xx:seasonSpring/xx:season /item the following from sourceB: item xx:seasonSummer/xx:season /item assuming both items have the same id (however expressed), everything else removed for clarity The RDF interpretation would be two statements, which could be wrapped back up into pseudo-RSS as: item xx:seasonSpring/xx:season xx:seasonSummer/xx:season /item The RDF/XML interpretation mechanism provides clear communication of data within a known data model. It's an unambiguous message in this model. What the application does with it is another matter - it's a different layer. But without such a mechanism, the choices are back down at the level of XML syntax, there isn't even a domain-specific grammar to draw on. (also please don't use the word receive, we request things around here) I'd suggest this all occurs above the wire protocol, but ok, I'll try not to ;-) Cheers, Danny. -- http://dannyayers.com
Re: Yahoo and Media RSS
On Thu, 16 Dec 2004 20:40:27 +, Graham [EMAIL PROTECTED] wrote:
On 16 Dec 2004, at 8:12 pm, Danny Ayers wrote:
xx:thing yy:another=elsewhere /
Where would you expect to the semantics of yy:another to be defined?
In the yy document, though possibly also in the xx document.
Ok, that would be my reading too.
Un-namespaced attributes are a different thing and a special case. Its
best to think of them as belonging to a special namespace:element
psuedo-namespace (ie the qname is namespace:element:attr), though
officially they belong to none at all.
I accept they're special case, but best to think of them doesn't
help much in implementations - according to that SAX trace I posted,
the Yahoo attributes are in the same namespace ('') as the core RSS
2.0 elements.
The RSS 2.0 spec says:
A RSS feed may contain elements not described on this page, only if
those elements are defined in a namespace.
but is (as far as I can see) silent on attributes, so perhaps the
Yahoo material is perfectly valid, as well as constructs like:
item number=123
...
Special case, as I said. It's
all in that errata document.
Where? I can't find anything that covers this case.
Cheers,
Danny.
--
http://dannyayers.com
Re: Yahoo and Media RSS
On Thu, 16 Dec 2004 18:23:53 -0500, Sam Ruby [EMAIL PROTECTED] wrote: Inferring that attributes which are in an explicit namespace are the same might be reasonable. But inferring that attributes which are not in a namespace are the same because they happen to be spelled the same may produce false positives. I'm a little tired right now so might be missing something obvious, but if you accept this latter point, then why shouldn't you also accept the same interpretation for element names - i.e. item / and item / may not actually be the same..? Cheers, Danny. -- http://dannyayers.com
Re: Priorities in Atom?
On Wed, 8 Dec 2004 04:35:48 -0500, Bob Wyman [EMAIL PROTECTED] wrote: Most of these things could be quite nicely handled by a simple tag/value structure. Something like: prop name=LinkRank333/prop prop name=BSValue$33.03/prop prop name=classificationpolitics/prop prop name=priorityvery_high/prop They could be handled this way, but as it stands there isn't any way of recognising the properties in an unambiguous fashion. I don't think a centralized registry is the answer either. But if there was a simple generalized interpretation of material from other namespaces, we can remove ambiguity and use the XML more like, errm, XML: e.g. entry ... pubsub:LinkRank333/pubsub:LinkRank ... /entry The spec could contain words to the effect that elements like this SHOULD be interpreted as a named property of the enclosing entry, the value being the child text node. The use of namespaces will avoid clashes, so this won't be interpreted as the same thing as google:PageRank333/google:PageRank. Let's focus on the mechanism for communicating properties rather then the specific properties that are to be communicated. Yes please. I'd favour something like Robert's PacePropertyDesign (which would probably find it's way to consensus without the RDF references). Cheers, Danny. -- http://dannyayers.com
Re: PaceFeedState server-side proof-of-concept implementation
I need to think some more about the idea of multiple feeds as static files, it does seem to be moving away from It's the Entries, though I can't actually see any real problem with that: It's the Entries = the packaging don't matter. Now then... FYI, I've put 'this' and 'prev' elements on my RSS feed as a proof-of-concept on the server side; see http://www.mnot.net/blog/index.rdf ...ok, proven at server side, now what might a client do with the data? (As it's RSS, something driven by Sparql queries might perhaps make a good demo..?) Cheers, Danny. -- http://dannyayers.com
Re: Work Queue Rotation #13
On Tue, 23 Nov 2004 09:39:50 -0500, Robert Sayre [EMAIL PROTECTED] wrote: Danny Ayers wrote: I appreciate Rob's effort to try and get some usable wording, but to me the suggested version (pasted below) seems too far removed from the world of resources and HTTP, also overly prescriptive. I don't think it needs a Pace, but does need revisiting. Too far removed from a requirement that isn't present, vague, and yet still overly precriptive. I've really accomplished something here. However, I find your objection insufficiently detailed. Show us a use case and a problem with the language in concrete terms. A Link construct is an empty element that describes a connection from an Atom document to another Web resource. Ok. Why not just leave it at that. Let me try to disambiguate the next bit to show why I don't think it works - When a link is activated, User Agents are expected to visit the linked resource, rather than apply metadata such as schema or styling information as is common in HTML dialects. = The User Agent will present the user with some form of interface component corresponding to the link construct through which they may interact (such as a hyperlink or button). The User Agent is expected to respond to interactions with that component by applying a HTTP GET to the resource identified by the URI and somehow processing the returned data. The construct should not be interpreted as a declarative statement of a relation between the Atom document and the identified resource, nor should the data returned by the GET be used for validation or display styling purposes. Why not just take the first sentence, and leave it to the definition of the 'rel' to explain the nature of the connection? What's wrong with purely declarative (non-hyperlink) connections? If a hyperlink really *is* all that's intended, then why not just say something like: the link element describes a hyperlink which the User Agent is expected to treat link a HTML anchor tag, providing HTTP access to the identified resource. Cheers, Danny. -- http://dannyayers.com
