Hiya, Ok, I'll be brave and cut down on the length a little bit without killing the "importance". :)
On Wed, May 28, 2008 at 6:25 PM, Steve Jones <[EMAIL PROTECTED]> wrote: > I do hope there are non-XML examples of modelling as well. I loathe > and detest XML, its sort of the democracy of document exchange (the > worst form, except for all the other ones). Always non-XML around. I don't detest XML per se, but what some people do with it. >> Ok, let's see if I can provide you with an example of resource >> oriented models in REST. I've changed from cars to planes (because I >> happen to have this data already), so hope you don't mind. Let's GET >> an IRI about the SAAB 35 Draken fighter plane ; > > BTW the following isn't (in my simple mind) a modelling notation ;) Well, it isn't notation in the generic sense, but it certainly depicts the model. Or, more specifically, it depicts model fragment results. I guess here comes another RESTful way of dealing with this; I'm dealing it out piecemeal, and you resolve the model until you're happy with it (or can work with it). In some ways, this is incredibly revolutionary way (and, I'm talking from my own perspective, of course) of dealing with interoperability of a complex nature as the cache and hyperlinks drives the state of the *model*. I find that very sexy. ... >> All these items normally have names, but hopefully they also should >> have PSD (descriptions, to make the ontological parts as clear as >> possible as to their neature and meaning). > > Or use a commonly agreed definition? There is no "or" in that; it's what the PSI / PSD mechanism is; shared agreement and definitions. ... > Now for data modelling I'm with you, I'm still struggling with the > functional modelling aspect as it seems some what hidden behind the > "POST" Ok, any examples of such which I can chew on? ... > Again I see this as a way to implement a modelled SOA rather than > being the modelling approach itself. For me what you've show is an > OrderService which enables you to order a bunch of things, or a > generic OrderService which has a series of concrete implementations. > You've then decided to implement that using REST (which effectively > means taking the generic and concrete path) which is fine. > I'm just not seeing the modelling bit. REST is here detached from resource orientation. In fact, through my Topic Maps background I've been doing resource orientation (in a specific sense) for years already. What I've got here are, as you say, examples of something modeled. To see what resource orientation does for the modeling exercise itself I'd use prose and notation language (or XML, just to piss some people off :). Heck, I use napkins a lot, too. But then, maybe I'm just not getting your point here. Is there any examples you could give of what you're missing? What would you do? ... > I'm not sure about no-inheritance. You've basically shown that a > specific example inherits information from a generic example haven't > you? That looks and smells like inheritance just implemented via > hyperlinks rather than a compiler. I've said that you indeed *can* have these things, but they would be part of the model you explicitly mark up, not part of some underlying assumption about the architecture of the systems. In other words, you can model up whatever you'd like, but there's no inherit (pun intended) constraints like that in resource orientation as such. >> This is a web; lots of resource representing various stuff, in a web, >> all typified (they all are a type of something, which can be >> resolved). When you understand how the web is put together, you can >> act on it through the REST mechanisms in a fairly uniform way, reusing >> your basic handling code pretty much for every single resource. There >> are less special cases you need to worry about. > > Assuming all the ontology stuff is done (big assumption). Why is that a big assumption? You already do ontology work, except you hard-code it in code and configuration files for your bus and network. Ontology work really is about detaching the systems specific ontology (name of tables and columns in databases, names of variables, names of API's, etc) in a way to free the data from its container (probably inspired by how some words have multiple meaning and can be in many categories at once). It's not as hokey as I may come across here. For example, Topic Maps delivers a meta data model which you extend to support any crazy modeling idea you have, so we've taken a half step forward but leaves a lot up to you to define, as opposed to the four steps forward of SemWeb (basic RDF, then RDFS, then three levels of OWL, and *then* your own models) but five steps back when you understand the constraints involved. Anyway, I like to detach my data from its containers, but many others don't, and I can understand why. ... >> Ok, what's an example of that sort of higher level, and let's see if I >> can help out somehow. > > http://blueprints.jot.com/WikiHome/SOA%20Business%20Blueprint > > With pictures. Basically this is how I model businesses and help them > re-organise their people and systems to match more effectively how the > business works. I might choose to use REST in certain circumstances > for implementation but the architectural model is SO. Ok, I see where you're going, and I think that no matter how much notation or XML I throw your way, they won't turn into drawings. :) Well, kind of. I do have a GraphViz engine that maps up Topic Maps, so I *can* use notation for what you draw and have both a drawing and a model and a RESTful interface to it, but I need a little bit more time than I have right now. (I assume you work too? :) But I'm keen on trying it out. My notation language looks a bit like this YAML friendly snippet: Manufacture [color:green]: -> Logistics & Warehouse ("Supply stock") Finance [color:pink]: <-> Manufacture ("Budget") <-> Marketing ("Budget") <-> Logistics & Warehouse ("Budget") <-> Sales ("Budget") Logistics & Warehouse [color:]: -> Manufactore ("Request stock") Marketing [color:blue]: -> Distributor Sales [color:gray]: -> Logistics & Warehouse ("Ship Order") -> Distributor ("Sell product") person:Plant Machinery Supplier person:Materials Supplier person:Logistics Company person:Distributor Each thing here is a resource, so ; http://example.com/core/manufacture http://example.com/core/logistics http://example.com/business/finance http://example.com/business/marketing http://example.com/business/sales http://example.com/parts/plant_machinery_supplier http://example.com/parts/raw_materials_supplier http://example.com/parts/logistics_company http://example.com/parts/distributor The relationships themselves are resources ; http://example.com/business/rel/budget http://example.com/business/rel/invoice http://example.com/business/rel/sell_product http://example.com/business/rel/ship_order Yes, I could put more effort into cooler IRIs for all these things, but we'll use these for now. In my notation I use URL Templating to specify these, for example ; Sales [color:gray tmpl:business/sales]: -> Logistics & Warehouse ("Ship Order" tmpl:rel/ship_order) -> Distributor ("Sell product" tmpl:rel/sell_product) And so on. The thing here is that the notation has converted all of this to a Topic Map. My RESTful framework just use this Topic Map as the application engine, and the mechanisms of REST delivers this piecemeal (or as big as requested). Ok, I assume you now want a link between this conceptual model, and the real world (or the real OO objects and software). I do this in either of two ways; if it's a straight easy task, I just have an action class for each resource, or, if there's more complexity not depicted in this model, I defer that resource to be a Topic Map in itself, with its own notation and resources, etc. I can here narrow the scope of the model as I dig deeper into the semantics of the problems the applications are trying to solve. this creates a nice link from the most conceptual to very specific models. And by "model", I include a simple struct of integers and floats as a model as well. Since all of them are resources with unique addressability, I can connect these otherwise disjoint pieces together if that makes sense to do (for example, a marketing campaign object in a CMS can have a direct link to the conceptual model of the "Target" link between Marketing and Distributor. Some applications can react to this relationship if they see fit, and they can either know about it or resolve it, or browse to it, ignore it, map it, etc. I guess the openness / addressability is what I'm mostly salivating over here. I'm fond of domain-driven design, but instead of doing that on the object level, I do that on the modeling and Topic Maps level, and feed that model to the REST framework. Resource orientation makes sure that the integrity I had in my conceptual model can be transfered to the actual implementation (no translation). If I choose do to so, the conceptual model is an actual part of the end product. Does this make sense? ... > It would take someone smarter than Einstein and Newton combined to be > able to look at the problem in totality and then sit down and write > the solution! Ok, off you go, then. :) ... > And the way they did that was to poison themselves to prove the point > (self-testing unsafe medical experiments being the only way to do it). That's the part of science I think I love the most. Not sure what that means. ... > What I mean is that having been on the skeptical camp around semantics > since I first saw it in academic anger in 2002 I still think that > sitting down and agreeing on things is a quicker and more secure route > than relying on semantic mappings. Well, if you look at it from the academic and SemWeb angle, I can certainly emphasize with your view. > The mappings can help you but what > can be miles more effective is a bunch of people sitting down and > saying "central database with all the codes in, codes written down as > a series of lines, bobs your uncle we've massively improved the global > supply chain" But you must admit that such system are rarely built for change, no? > Lots of people agree how to interact without an RDF, OWL/S or other > semantic technology. Possibly true, although I suspect the efforts going into agreeing sometimes are just so huge, so intense, so politically charged. Inference does have some areas in which it *will* kick ass and revolutionize the way we do things. Which areas is yet to be seen, however, and that this area is somewhat muddy doesn't help things along right now. ... my example ... > But this doesn't say how they work together and collaborate, it says > they are in the same team but doesn't say what their measures are an > how those cascade from the team downwards etc. In otherwords how are > tactics applied to that next work etc. I could do all that, I just thought I'd give you the small pitch instead of the 500Kb example. And, I don't sit around picking my nose all day, so time is scarce, but yes, I could do more if you like. :) But maybe give me a few concrete examples of how tactics are applied to the stuff you do? > Which is where I see the stuff above as implementation rather than > modelling. The first thing I'd like to know is the model, I'm just > not seeing models above I'm seeing implementation examples. It was there in how the XML snippets were bound together. Maybe you're after one whopping XML or notation language file which has a complete model for you to work with. I could provide that, too, but I prefer - no, I insist! - on the piecemeal delivery and how REST can cache it and get just enough to do that little thing it needs to do. I find that so cool, and you won't find it in the SOAP stack. > I'm thick so it takes me a while Hey, I'm Norwegian, so this could take even longer ... Alex -- --------------------------------------------------------------------------- Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps ------------------------------------------ http://shelter.nu/blog/ --------
