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
Saturday, January 8, 2005, 9:59:12 AM, you wrote: 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. I think that reason that RDF is only helping partially here is that you have a simplified model of an entry that is actually only modelling the state of an entry at a point in time, when actually entries are expected to vary over time and have multiple instances. This is fine, it is a useful simplification; models are supposed to be simplifications. But you can't then expect to merge two different instances of the entry under this model using simple RDF graph merging, because the model is an over-simplification. Eg: If you merged: entry idhttp://123/id date2005-02-03/date seismo:magnitude7/seismo:magnitude /entry and entry idhttp://123/id date2005-02-04/date seismo:magnitude7.5/seismo:magnitude /entry ... you would get: entry idhttp://123/id date2005-02-03/date date2005-02-04/date seismo:magnitude7.5/seismo:magnitude seismo:magnitude7/seismo:magnitude /entry Not very useful. A solution for RDF-based applications wanting to merge incoming RSS and get a consistent RDF model is to either have special application-level merging logic that knows about the simplification that has been made; or to have a model where instances of an entry are modelled explicitly. If the instances have ids, then you can allow for both posting new instances of entries, and annotating existing instances with extra information. Its a tradeoff between flexibility and complexity. -- Dave
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: Atom extensibility
Tim Bray wrote: I think that the charter requirements on extensibility will be filled adequately with PaceExtendingAtom. I think they would be filled still better by adopting PaceMustUnderstandElement, but apparently others are unconvinced. Extensibility via a mapping to RDF seems to me to add a lot of complexity (most people have never bothered to learn graph theory) without any real benefit. -Tim I won't talk about 'complexity' here, but will talk about cost/benefit. My take on this is that extensibility via a mapping to RDF seems to me to add cost for implementors and those processing Atom. Writing Atom as RDF is cheap enough. Not enough people are processing RSS1.0 and other RDF formats *as* RDF; I speculate that indicates an issue on receipt of the data. I'm +1 on not requiring an RDF mapping for Atom. Those of us that like to use RDF can figure out how to. cheers Bill
Re: RSS extensibility
Tim Bray wrote: Would you be satisfied with a paragraph that says that those who extend Atom may do so by putting in namespaced elements, and that such elements, when the information they contain is relevant to an entry, SHOULD appear as a child of atom:entry? Replace 'extend' with 'add information' and I'm +1. cheers Bill
Re: RSS extensibility
David Powell wrote: But you can't then expect to merge two different instances of the entry under this model using simple RDF graph merging, because the model is an over-simplification. Eg: If you merged: entry idhttp://123/id date2005-02-03/date seismo:magnitude7/seismo:magnitude /entry and entry idhttp://123/id date2005-02-04/date seismo:magnitude7.5/seismo:magnitude /entry ... you would get: entry idhttp://123/id date2005-02-03/date date2005-02-04/date seismo:magnitude7.5/seismo:magnitude seismo:magnitude7/seismo:magnitude /entry Not very useful. That's a versioning problem. While I haven't found basic RDF to be useful for that, I could imagine finding an 60% solution with something like OWL. XML is of no help here. The usual answer is to use a version control system to record state in time series or allow update semantics to your persisted representations if you don't care about past state. Incidentally I do believe that being able to track state or trends in a time series fashion has commercial value in the syndication market. cheers Bill
Re: Hash for Links [Was: Re: Posted PaceEnclosuresAndPix]
link rel=enclosure href=http://example.com/somefile.mp3;
hash={generated_hash_value}
hashalg={uri_identifying_the_hash_algorithm_used /
The hash and hashalg attributes would be optional but MUST appear together.
Thoughts? (If we have more than two people respond favorably to this,
I'll write up a Pace for it)
Seems like a good idea - would it be possible to move them into elements?
link rel=enclosure href=http://example.com/somefile.mp3;
hash hashalg=/
/link
How does that tee up for signing the markup, or just the hash+alg pair?
cheers
Bill
Re: Atom extensibility, RDF, and GRDDL
On Jan 8, 2005, at 8:23 AM, Bill de hÓra wrote: My answer to this question is that Atom doesn't have a model in terms of being able to talk about extension so there's no point discussing it. Extensibility is probably out of scope for the format. I'm not going to let that go unchallenged. The ability to put your own markup in a feed entry and be confident that it will not cause receiving software to break, and that it will be there for receiving software that actually knows how to deal with it, is what many people describe using the word extensibility. I think that Atom is, in a popular usage of the term (a large majority usage, I'd bet, but without backing statistics) extensible. The people who insist that you have to have to buy into a graph-theoretical KR model to be able to use the word extensible live in a universe that is self-consistent, but it's not the one where I work. -Tim
RE: Closure on Extensibility RDF
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Bray Sent: Saturday, January 08, 2005 10:49 AM To: 'Atom WG' Subject: Closure on Extensibility RDF [On behalf of Paul and myself:] The opinion has been forcefully expressed that Atom should adopt an extensibility framework based partly or wholly, directly or indirectly, on RDF. This idea is not unreasonable on the face of it. Thus, the time has now come to put this into a concrete proposal. Since we've talking about it for months, this shouldn't take long. Would the advocates of this view please, by Monday January 17th, bring the WG a proposal for its consideration. This could take one of these forms: Hehe. I finally post a long-winded message on the subject and then within moments I receive this in my inbox. I'll definitely give Tim's message a think, along with the replies to it, over the weekend. Have a good weekend everyone. Jeremy PS - Henry, Danny, Bill/Bill, et al - I know its been a while since I've been actively involved, but now looks like it would definitely be the right time, if any. If I can be of any assistance, whether in looking over draft text and/or playing devil's advocate in any conference calls, email threads, IRC chats, whatever, please feel free to get in touch. In the meantime, I'm going to think about a few extensibility experiments I have in mind, and will let you know if anything interesting comes of them.
Re: Hash for Links [Was: Re: Posted PaceEnclosuresAndPix]
I require this functionality in content src=. There is aboslutely no way I'm initiating 20 HTTP requests (even HEADs) each time the feed is reloaded. Graham smime.p7s Description: S/MIME cryptographic signature
Re: Closure on Extensibility RDF
At 8:33 PM +0100 1/8/05, Henry Story wrote: Here is one suggestion I was thinking of to move along, quickly and seamlessly I hope. All that seems fine, but your list is neither a Pace nor an Internet draft, and is therefore not in line with what Tim and I asked for. Given that you talk about an IETF document, I am assuming that you intend to write the Internet Draft, yes? --Paul Hoffman, Director --Internet Mail Consortium
Re: Closure on Extensibility RDF
The IETF document I mentioned is the one this mailing list is working on developing. The four points I listed are starting points for a couple of small additions to the Atom IETF document and their relation to a to be written OWL Ontology. There are I am sure people more familiar with the ins and outs of this standards process that will know how to turn that general idea into more specific and acceptable proposals. Henry On 8 Jan 2005, at 21:50, Paul Hoffman / IMC wrote: At 8:33 PM +0100 1/8/05, Henry Story wrote: Here is one suggestion I was thinking of to move along, quickly and seamlessly I hope. All that seems fine, but your list is neither a Pace nor an Internet draft, and is therefore not in line with what Tim and I asked for. Given that you talk about an IETF document, I am assuming that you intend to write the Internet Draft, yes? --Paul Hoffman, Director --Internet Mail Consortium
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: Comment on process
No-one gains anything from overly protracted discussion. But I don't seen any extraordinary circumstances that might justify the imposition of cloture. Is there something related to the (still unexplained) deadline mentioned in Tim's recent post? I'm not sure that I understand why you believe the deadline is unexplained. Take a look at the charter for this working group: http://www.ietf.org/html.charters/atompub-charter.html There are goals and milestones identified with due dates. The working group chairs have an obligation to keep the working group on track to meet those milestones. They can set interim goals for smaller tasks if they feel it's necessary. Given that the goals and milestones were agreed upon as part of the creation of this working group, what's not clear? -Scott- (atompub area advisor)
Re: Comment on process
On Jan 8, 2005, at 2:03 PM, Danny Ayers wrote: No-one gains anything from overly protracted discussion. But I don't seen any extraordinary circumstances that might justify the imposition of cloture. Is there something related to the (still unexplained) deadline mentioned in Tim's recent post? Tim already said (before yet another round of RDF waffling started) that the chairs were seeking to produce a final draft. What he did was extend his own deadline to give you time to make a concrete, forward proposal on what needs to be done, either in a PACE (like everyone else) or in a separate draft. If you can't do that in four days then it isn't going in the next draft, which is the only horizon that chairs have control over. As far as process goes, Tim (and Paul) have been exceedingly kind. I would have simply said Put up or shut up some six months ago and further discussion would be out of order until such time as there is a concrete proposal to be discussed. IETF WGs move forward on the basis of rough consensus and running code. Roy
Re: Comment on process
At 11:03 PM +0100 1/8/05, Danny Ayers wrote: I am optimistic a compromise on the extensibility/RDF issue can be reached in the given time frame, Good! but find the imposition of such a short period a bit extreme. The WG has been discussing this for *months*. The fact that the chairs have put an end-point on those months does not make the total time a short period. Given the amount of discussion so far, do you really believe it is impossible to put together a concrete proposal either as a Pace or as an Internet Draft in a week? If so, that indicates that the problem is not describable enough for inclusion in a standard. Tim and I believe that there are some people in the WG who don't believe that, but we need to see proof. I doubt anyone reading Tim's recent posts on the subject of extensibility could come to any conclusion other than that he is vehemently opposed to any inclusion of anything associated with RDF in the core specification. Tim has most recently said The opinion has been forcefully expressed that Atom should adopt an extensibility framework based partly or wholly, directly or indirectly, on RDF. This idea is not unreasonable on the face of it. I cannot parse that in any way that leads to a belief that he is vehemently opposed so such inclusion; the opposite seems much more true. What he and I are asking for is to finally finish. We've talked enough; give a proposal for how to move forward so the WG can come to consensus. Isn't this the first time a strict deadline has been imposed for proposals for any set of features? (Aside of course from the name). Not at all. It has happened many times in the past. Each time we solicit to close issues, there is a (usually implicit) deadline for responding to that call. This is no different, except that we still don't have a Pace or Internet Draft to work from. So, the chairs have two choices in order to come to closure soon on the discussion that is of interest to everyone here: a) Say there is still no proposal, so closure is reached in the negative b) Say we will soon reach closure in the negative unless someone posts a concrete proposal we can find consensus around. At least to me, (b) seems like the better option, yes? No-one gains anything from overly protracted discussion. Fully agree. But I don't seen any extraordinary circumstances that might justify the imposition of cloture. Agree. That's why we are asking for a proposal that we can discuss. Is there something related to the (still unexplained) deadline mentioned in Tim's recent post? See Scott's response, with which I fully agree. --Paul Hoffman, Director --Internet Mail Consortium
Re: Closure on Extensibility RDF
At 10:54 PM +0100 1/8/05, Henry Story wrote: The IETF document I mentioned is the one this mailing list is working on developing. Then you didn't understand Tim's message. He meant a *new* Internet draft, not a change to the current draft (unless the change is a few sentences). From your list of changes, it doesn't seem like it is just a few sentences, so you need to submit a separate Internet Draft, initially as an individual submission. If the WG agrees that it should be a WG work item, it will change into one; otherwise, you can pursue it as an individual document, probably still discussing it on this mailing list. The four points I listed are starting points for a couple of small additions to the Atom IETF document and their relation to a to be written OWL Ontology. There are I am sure people more familiar with the ins and outs of this standards process that will know how to turn that general idea into more specific and acceptable proposals. See Tim's message. You do this by creating either a detailed Pace or a complete Internet Draft. --Paul Hoffman, Director --Internet Mail Consortium
Re: Closure on Extensibility RDF
The internet draft I want to propose is an OWL document. I can get this out tomorrow. It will essentially say everything the current Atom OWL spec says, but in machine readable form. All that is required then is that the Atom IETF document this working group is working on have some language describing its relation to the OWL document. This need not be a very big change to the current document. I believe it could be done in a few sentences taking my first proposal as a guide. If anyone has some good ideas on where it would be best to change the language, please help me along and write that out. I can do with all the help out there :-) Understand that all I am proposing is a machine readable rewriting of what the current Atom spec says. That is most of what there is to it. The rest is just asking for a little good will. Yours sincerely, Henry Story http://bblfish.net/blog/ On 8 Jan 2005, at 23:35, Paul Hoffman / IMC wrote: At 10:54 PM +0100 1/8/05, Henry Story wrote: The IETF document I mentioned is the one this mailing list is working on developing. Then you didn't understand Tim's message. He meant a *new* Internet draft, not a change to the current draft (unless the change is a few sentences). From your list of changes, it doesn't seem like it is just a few sentences, so you need to submit a separate Internet Draft, initially as an individual submission. If the WG agrees that it should be a WG work item, it will change into one; otherwise, you can pursue it as an individual document, probably still discussing it on this mailing list. The four points I listed are starting points for a couple of small additions to the Atom IETF document and their relation to a to be written OWL Ontology. There are I am sure people more familiar with the ins and outs of this standards process that will know how to turn that general idea into more specific and acceptable proposals. See Tim's message. You do this by creating either a detailed Pace or a complete Internet Draft. --Paul Hoffman, Director --Internet Mail Consortium
Re: Closure on Extensibility RDF
On 9 Jan 2005, at 00:06, Henry Story wrote: The internet draft I want to propose is an OWL document. I can get this out tomorrow. It will essentially say everything the current Atom OWL spec says, Sorry it is past midnight here at I am typing a little fast. I meant It will essentially say everything the current Atom spec[1] says, [1] http://ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub- format-03.txt but in machine readable form. All that is required then is that the Atom IETF document this working group is working on have some language describing its relation to the OWL document. This need not be a very big change to the current document. I believe it could be done in a few sentences taking my first proposal as a guide. If anyone has some good ideas on where it would be best to change the language, please help me along and write that out. I can do with all the help out there :-) Understand that all I am proposing is a machine readable rewriting of what the current Atom spec says. That is most of what there is to it. The rest is just asking for a little good will. Yours sincerely, Henry Story http://bblfish.net/blog/ On 8 Jan 2005, at 23:35, Paul Hoffman / IMC wrote: At 10:54 PM +0100 1/8/05, Henry Story wrote: The IETF document I mentioned is the one this mailing list is working on developing. Then you didn't understand Tim's message. He meant a *new* Internet draft, not a change to the current draft (unless the change is a few sentences). From your list of changes, it doesn't seem like it is just a few sentences, so you need to submit a separate Internet Draft, initially as an individual submission. If the WG agrees that it should be a WG work item, it will change into one; otherwise, you can pursue it as an individual document, probably still discussing it on this mailing list. The four points I listed are starting points for a couple of small additions to the Atom IETF document and their relation to a to be written OWL Ontology. There are I am sure people more familiar with the ins and outs of this standards process that will know how to turn that general idea into more specific and acceptable proposals. See Tim's message. You do this by creating either a detailed Pace or a complete Internet Draft. --Paul Hoffman, Director --Internet Mail Consortium
Re: Closure on Extensibility RDF
At 12:06 AM +0100 1/9/05, Henry Story wrote: The internet draft I want to propose is an OWL document. I can get this out tomorrow. It will essentially say everything the current Atom OWL spec says, but in machine readable form. An OWL document is not an Internet Draft. If you cannot create an Internet Draft, please find someone who agrees with your desires to help you. All that is required then is that the Atom IETF document this working group is working on have some language describing its relation to the OWL document. That should be included in your Internet Draft. This need not be a very big change to the current document. That remains to be seen. The best way we can see it is in your Internet Draft. Clearly, if it is a small change and the WG wants to use it, it can be folded into the main document before we send it to the IETF. I believe it could be done in a few sentences taking my first proposal as a guide. Great! Let's see them. If anyone has some good ideas on where it would be best to change the language, please help me along and write that out. That is actually the least important point in your proposal, and the easiest to take care of late in the process if the WG agrees to the incorporation. If the WG doesn't agree to the incorporation, it isn't needed at all in your Internet Draft. I can do with all the help out there :-) So can we all... Understand that all I am proposing is a machine readable rewriting of what the current Atom spec says. In order for us to verify that statement, we need to see the rewriting, and we need to hear from a few people who understand OWL saying yup, that exactly matches what is in the format draft. That is most of what there is to it. The rest is just asking for a little good will. Fully disagree. The rest is the WG coming to consensus on whether or not we want this as part of the baseline spec. Given this WG's propensity to disagree about most things XML and RDF, assuming that will come easily is not based on even a casual reading of the mailing list. --Paul Hoffman, Director --Internet Mail Consortium
Re: Closure on Extensibility RDF
I can't do everything simultaneously. Tomorrow I will give you a first version of an OWL document that will map the current atom spec. Can you give me the current namespace for the draft atom spec I am supposed to be working to? This is so the atom OWL document can describe the properties of the draft atom spec. The url of the location of the directory of the draft spec will probably do. Then I can define the properties of atom:content using the full url say http://purl.org/atom/#content When someone clicks on that link with a browser that asks for the content as text/simple they will get the current atom draft spec. When they ask for it using the mime type application/rdf+owl they will get the document I will present you tomorrow. With this document at hand it will be a lot easier to explain the relation between the spec and the OWL document, either in the current atom spec, or if you really insist, in a separate Draft. That will be machine interpretable xml, ie: running code. Good night, Henry Story On 9 Jan 2005, at 00:25, Paul Hoffman / IMC wrote: At 12:06 AM +0100 1/9/05, Henry Story wrote: The internet draft I want to propose is an OWL document. I can get this out tomorrow. It will essentially say everything the current Atom OWL spec says, but in machine readable form. An OWL document is not an Internet Draft. If you cannot create an Internet Draft, please find someone who agrees with your desires to help you. All that is required then is that the Atom IETF document this working group is working on have some language describing its relation to the OWL document. That should be included in your Internet Draft. This need not be a very big change to the current document. That remains to be seen. The best way we can see it is in your Internet Draft. Clearly, if it is a small change and the WG wants to use it, it can be folded into the main document before we send it to the IETF. I believe it could be done in a few sentences taking my first proposal as a guide. Great! Let's see them. If anyone has some good ideas on where it would be best to change the language, please help me along and write that out. That is actually the least important point in your proposal, and the easiest to take care of late in the process if the WG agrees to the incorporation. If the WG doesn't agree to the incorporation, it isn't needed at all in your Internet Draft. I can do with all the help out there :-) So can we all... Understand that all I am proposing is a machine readable rewriting of what the current Atom spec says. In order for us to verify that statement, we need to see the rewriting, and we need to hear from a few people who understand OWL saying yup, that exactly matches what is in the format draft. That is most of what there is to it. The rest is just asking for a little good will. Fully disagree. The rest is the WG coming to consensus on whether or not we want this as part of the baseline spec. Given this WG's propensity to disagree about most things XML and RDF, assuming that will come easily is not based on even a casual reading of the mailing list. --Paul Hoffman, Director --Internet Mail Consortium
Please Review: Dissemination of Earthquake / Tsunami data via Atom
At PubSub, were beginning to put together a live feed of earthquake and tsunami information in the hope that by making this information more widely and rapidly disseminated, well be able to prevent at least a tiny amount of the troubles such as recently happened in the Indian Ocean. In collecting this data, were not simply polling the USGS RSS feeds doing that would introduce too much latency in the process and such high latency or delays would be unacceptable for this kind of data. What were doing is connecting to live push feeds of data and then executing on our servers the complex and messy clean-up, validation and reformatting processes that are required. The instant we have good data, we push it out to our subscribers using Atom over XMPP/PubSub and, as always, insert the latest messages into our subscribers personal Atom and/or RSS files. This service will be made available for at least experimental use in a few days after weve completed some testing. We currently expect to provide both traditional PubSub subscription service as well as a telnet feed of raw data that other service providers will be able to use to build their own systems. We think it is appropriate to feed this kind of data over PubSub and in Atom files but before we get too far down this road, Id like to get some input from the Atom community about the format were thinking about using. A sample Atom 0.3 entry from the current system is provided below. Please take a look at it, provide whatever comments you consider appropriate and also consider my questions below: 1. The first thing to note is that the content is xml, not text or XHTML. The thinking here is that we really want to be able to provide data to end users since it is likely that the best way to use this data is to have some kind of application (like a mapper, etc.) that would process the data. It is, I think, less interesting to provide text. However, some folk will want a machine generated textual version of this message Since Atom only allows us one content element, there is no way to do both data and text or, am I missing something? (Note: I do not want to convert this XML to XHTML) 2. Ive been thinking that I might include an atom:summary element that contained a textual version of the XML data carried in the content field. However, it appears that most aggregators today display either the summary or the content but dont display both... 3. Ive provided a rel=alternate link that points to a USGS generated HTML page describing the event. Is it legitimate to point to an alternate that I havent created myself? 4. The title field provides some reasonably compact user data summarizing the key data for the event. Would that be sufficient as a textual representation? 5. What should a client do when presented with this data? Clearly, there are all sorts of interesting things that one can do if you know the format and build a custom app. However, it would be nice to allow dumb clients to do something useful without having to force the format to lowest-common-denominator (i.e. HTML or XHTML). I think what Id like to do is provide a pointer to an XSL-template in some standard manner. Then, a client could fetch the style sheet and generate something for display. Is this reasonable? If so, where would I identify the style sheet? 6. This kind of data is really sensitive I would very much like to be able to use a Digital signature to ensure that we can repudiate any fake messages that might get generated by spammers and other idiots as well as to repudiate mangled versions of the data that might get produced down-stream of us. The subject of signing Atom entries doesnt seem to be getting much attention. Can we wake this one up again? I really do not think that signing should be considered something outside the core and subject to individual or proprietary extensions. I look forward to your comments and assistance in getting this system working hopefully, long before the next disaster in which it might be useful. bob wyman Note: The message below was published long after the original event. The reason for the delay is that this message adds to information previously published much closer to the time of the event. (i.e. the AddOn element with the links to the waveforms was not available when the event was first published.) If a tsunami warning was issued, it would also appear as an AddOn. entry modified2005-01-08T16:49:18-05:00/modified issued2005-01-08T16:49:18-05:00/issued ididtag:pubsub.com,2005:EQ:ci14117540/id/id titleM 1.8 SOUTHERN CALIFORNIA 2005-01-08T21:00:21.000Z/title link rel=alternatehttp://earthquake.usgs.gov/recenteqs/Quakes/ci14117540.htm/link content type='text/xml' xmlns='http://pubsub.com/xmlns' Message topicEarthquakes/topic publisherPubSub Earthquake Publisher/publisher messageID14117540/messageID revisionID2/revisionID publication-date2005-01-08T16:49:18-0500/publication-date contentTypeEQMessage/contentType
Re: Atom extensibility, RDF, and GRDDL
Bill de hÓra wrote: Look, the point is this. Those arguing from the RDF side of the house do mean what you mean by extensible. Furthermore, what is meant there by Dammit. Sorry, that should be, those arguing from the RDF side of the house do *not* mean what you mean by extensible. cheers Bill
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: The Atom Format end-game (PICS)??
Tim Bray wrote: 2. We are close to RSS2 feature-compatibility, we either adopt image enclosure or make a conscious decision not to. There are other bits of RSS2 that should be seriously considered -- even if they aren't widely used. For instance, the RSS2 rating element which contains a PICS[1] statement. As far as I know, virtually noone uses the rating tag in RSS2.0. Nonetheless, it would probably be wise to support such a thing in Atom. As blogging goes mainstream, we should be able to show that mechanisms at least exist to do what PICS is attempting to do... bob wyman [1] http://www.w3.org/PICS/
