[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Something altogether different?

• To: Michael Champion <michaelc.champion@g...>
• Subject: Re: Something altogether different?
• From: Bill de hÓra <bill.dehora@p...>
• Date: Mon, 25 Apr 2005 12:47:57 +0100
• Cc: XML Developers List <xml-dev@l...>
• In-reply-to: <e3a5cb2c0504240754423b2b8a@m...>
• References: <830178CE7378FC40BC6F1DDADCFDD1D102767584@R...> <426BA865.3050208@p...> <e3a5cb2c0504240754423b2b8a@m...>
• User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

Michael Champion wrote:

> What Dare actually said was "What Bosworth is pointing out is that the
> Web is different from 'the enterprise'. XML technologies over the past
> few years have been hijacked by enterprise concerns. It is telling
> that XQuery is now primarily being driven by relational database
> vendors and WS-* is basically taking on the use cases of
> DCOM/CORBA/etc for the Enterprise. These may all be the right
> solutions on the intranet or within the firewall (maybe) but they are
> too complex for the worse-is-better world that is the Web.Using RSS as
> the primary data format for the Web (in the same way HTML is the
> primary document format) isn't as crazy as it sounds."
> 
> Which part of that do you disagree with, Bill?

Why are you asking? ;)


> The part I'm most skeptical about is
> "standardization" -- how will people agree on on tags, microformats,
> namespaces, etc. whatever needed to extend RSS to cover restaurant
> reviews, product catalogs, etc. etc. etc.?

I see RSS/Atom pecking away at enveloping and packaging technologies 
such as SOAP, maybe even MIME, rather than content formats. Also, 
RSS/Atom provides a cheap way to do discovery in a Web where everything 
is only one click away, if only you know which one click. Personally I 
didn't really 'get this' until I started working with Atom over XMPP, 
but my gut feeling is that the 'feed' is an artifact of working with 
HTTP as much as anything else. Planet* feeds eating up UDDI usecases is 
not far fetched.

In terms of being able to uniformly process the /data/ in the  entries, 
RDF remains an option, purely because a lot of the hard work of  how to 
combine and extend data has been done - especially how to reference 
domain entities with metadata. So, imo, putting RDF blocks inside Atom 
entries can get useful work done reasonably cheaply. But you can go a 
long long way by sprinkling span[@class=''] pixie dust on XHTML and 
scripting against it. Atom for example, has invented a description 
language for links using a couple of attributes and well know values - 
it extends by allowing you to make up more well-known values which you 
are expected to code against.

At this point I should say that my RSS/Atom usecases are outside the 
dominant case of getting blog entries into aggregators. For example, 
slinging stuff like this about (much elided):

<atom:feed version="0.3" xmlns:atom="http://purl.org/atom/ns#">
   <atom:title/>
   <atom:link rel='alternate' type='application/xml' href=''/>
   <atom:modified/>
   <atom:author><atom:name/></atom:author>
   <atom:entry>
     <atom:title/>
     <atom:link rel='alternate' type='application/xml' href=''/>
     <atom:id/>
     <atom:issued/>
     <atom:modified/>
     <atom:content type="application/rdf+xml" mode="xml">
       <rdf:RDF
         xmlns:iam="http://www.reach.ie/iams/envelope/"
         xmlns:event="http://www.reach.ie/iams/event/"
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
         <event:Event>
           <event:EventSourceTime/>
           <event:EventSource rdf:resource=""/>
           <event:EventLevel rdf:resource=""/>
           <event:EventDescription/>
           <event:EventObject rdf:resource="" rdf:type=""/>
         </event:Event>
         <rdf:Description rdf:about="">
           <iam:Version/>
           <iam:MessageType rdf:resource=""/>
           <iam:MessageRole rdf:resource=""/>
           <iam:MessageSource rdf:resource=""/>
           <iam:EnvelopeType rdf:resource=""/>
           <iam:MessageSourceID/>
           <iam:MessageDestination rdf:resource=""/>
           <iam:CorrelationID rdf:resource=""/>
           <iam:MessageID rdf:resource=""/>
           <iam:SequenceNo/>
         </rdf:Description>
       </rdf:RDF>
     </atom:content>
   </atom:entry>

   ...

</atom:feed>


Incidentally, the server that receives this stuff logs it, parses out
the RDF goo in the feed entries and forwards that to an RDF aware layer 
where it gets stored for later querying. However you could replace the 
Atom above with RDF1.0 and let the entire feed pass straight through to 
the RDF aware layer - nothing would break. This kind of flexibility is 
worth keeping in mind the next time someone here dings RDF because it 
can't describe Fahrenheit to Celsius conversions. It ain't pretty, but 
it does have interesting properties, Turing completeness not being among 
them.


> The obvious answer is that what Google (especially Froogle) looks for
> in markup, Father Darwin will deliver.   

You mean the folks who are asking the world to pepper their markup with
@rel=nofollow? Interesting move, to ask for structured metadata like
that ;)

> I guess I'm coming around to Dare's point of view --

That's cool, because it does seem to work in a number of cases.

cheers
Bill

• Follow-Ups:
  • Why not RDF rather than RSS for the Web of Data? - was Something altogether different?
    • From: Michael Champion <michaelc.champion@g...>

• References:
  • RE: Something altogether different?
    • From: "Dare Obasanjo" <dareo@m...>
  • Re: Something altogether different?
    • From: Bill de hÓra <bill.dehora@p...>
  • Re: Something altogether different?
    • From: Michael Champion <michaelc.champion@g...>

• Prev by Date: Re: Something altogether different?
• Next by Date: RE: Something altogether different?
• Previous by thread: Re: Something altogether different?
• Next by thread: Why not RDF rather than RSS for the Web of Data? - was Something altogether different?
• Index(es):
  • Date
  • Thread