I'd definitely concur with this.

I recently had a teleconference with a group that was trying to understand how the Semantic Web could be used for services discovery - i.e., applying RDF, etc., to areas that people tried originally to cover with UDDI. In trying to lay this out, one of the first things that I did with them was to move the discussion away from discovery of services and process - which XML and the web are both notoriously poor in handling - and instead moving towards the discovery of resources and the importance of RESTful services and approaches in application development.


For some reason, this is an exceptionally hard sell to both programmers and business people, I suspect because both groups are commissioned to think in terms of process flow and workflow. Yet if you can get people to understand the value of modeling resources first then simplifying the interfaces to semantically neutral publishing operations, it's surprising how readily you can get past the political BS.


One thing I did realize recently in RESTful services models, however - sometimes resource coupling is unavoidable. The classic model for this is the notion of posting an XML model to a validating collection (i.e., one that applies a server-centric validation test) still needs to provide some mechanism for communication at a level beyond HTTP numeric codes. It occurred to me that if you were to attach an action (say an XQuery script) to the appropriate REST URL (such as creating a message logging the PUT interactions to a given service that can be downloaded under separate process), this makes it possible to keep the publishing semantics clean while simultaneously letting you handle necessary coupling in a transparent manner.


My belief is that we're only just beginning to understand the best practices model for working effectively with REST based systems.

Kurt Cagle

On Sun, Oct 5, 2008 at 3:05 PM, Michael Kay <mike@s...> wrote:






 

  
  In my experience designing ontologies for different groups, one 
  thing that I find keeps cropping up is that SMEs tend to create data 
  structures that most closely approximate their understanding of a subject, not 
  necessarily that provides the most optimal representation of that data 
  model.  
   
  My experience is complementary: I usually find that different 
  business people have 
  different perspectives on the information, and your job as data architect is 
  to moderate / facilitate dialogue / knock heads together.
   
  My first ever XML job was to design some application-interchange 
  messages for a cable TV company. Not seen by them as a data architecture job 
  let alone a business consultancy job; but within a couple of days I was 
  moderating an animated discussion between people from different divisions 
  of the company about whether or not their business plan included selling to 
  hotels or not. So: never assume that anyone you are talking to has the whole 
  picture.
   
  In this particular company the business people were much more inclined 
  to think in terms of business processes than information assets, so the 
  business process tended to be the starting point. But they were a lot more 
  interested in processes that were useful to the business, like installing new 
  customers, than into "grudge processes" like disconnecting ex-customers. When 
  you started discussing how things like that were supposed to work, they would 
  quickly lose interest and say "just make it happen".
   
  Michael Kay
  http://www.saxonica.com/


-- 
Kurt Cagle
Managing Editor, xml.com
O'Reilly
kurt@o...