- From: Mark Baker <distobj@acm.org>
- Date: Tue, 7 Jan 2003 00:09:46 -0500
- To: Walden Mathews <waldenm@optonline.net>
- Cc: www-ws-arch@w3.org
Hi Walden, On Mon, Jan 06, 2003 at 09:52:22PM -0500, Walden Mathews wrote: > Mark, > > > For example, assuming that a URI was tagged with "ibm-related-things", > > then an app written to grab and analyze stuff related to IBM would > > want to recognize that element and invoke GET on the URI. A wide > > variety of forms of data could be returned for analysis, including > > data that doesn't have anything to do with IBM; a runtime type > > error (which should indicate that binding is still late). > > > > In other words, "ibm-related-things" is a partial specification, leading to > immediate partial understanding, which can be developed into full > understanding by the coordinating applications if the ROI warrants > that, and the ROI calculation can be performed at runtime, not design > time, but actually at either time. > > Comments? Heh, I thought about getting into partial understanding, but avoided it. But no, I wouldn't say this enables partial understanding, since understanding "ibm-related-things" is an all-or-nothing proposition. In order to enable partial understanding, you'd need a shared data model that could describe what an "ibm-related-thing" is in terms of other things which may be known (dare I say "RDF"?). > So when the app does GET on the URI, it gets something it wasn't > anticipating, and then has to make sense out of that. But not necessarily > complete sense. It can weed out irrelevant content based on some > heuristic. The remaining question is: when the app wants to do something > other than snoop around, how is the understanding gained? As above, it's gained by having it be related to other things, some of which may already be known (and having already deployed enough general stuff that everything can be related to like RDF, RDFS, DAML, OWL). For example, if our IBM-analyzing app knew that "http://foo.org/relatedTo" meant "related-to" (i.e. it was hardcoded to know that) and ran across an RDF SPO triple; <http://www.sun.com> <http://foo.org/competitorOf> <http://www.ibm.com> It might see that IBM was the object, but not recognize the predicate. So it could do a GET on it to discover a triple like this; <http://foo.org/competitorOf> daml:subClassOf <http://foo.org/relatedTo> (where "daml:subClassOf" is presumed to be known since it's part of DAML, and means sub-class-of as you'd expect) This tells the client that the "http://foo.org/competitorOf" predicate can be treated as if it were "relatedTo". The client could then conclude that http://www.sun.com identified a resource which was related to IBM, and report that in its analysis, even though it doesn't know what a competitor is. And that's just the simplest form of partial understanding. > How does > that differ from the WSDL method? How "late" can WSDL be bound? WSDL describes interfaces. It can describe interfaces which are used in a late bound scenario, no problem. What that entails is defining an interface which doesn't map directly to the interface of your application objects, i.e. it provides an abstraction. Clients couple to this abstraction, deferring the determination of which application object and method gets invoked until runtime. So there aren't "degrees of late binding", but there are degrees of generality of the abstract interfaces used in late binding. For example, the Shape[1] abstraction is wonderful for dealing with shapes of all kinds, but it can't easily be used (well, had I done a better job and populated it with more shape-specific methods 8-) for other stuff that aren't shapes. > Is there some limit where both approaches converge? I don't believe so. > Is the benefit of > late binding to be expressed just in the tightness of feedback loops, or > something else? Not sure what you mean by "feedback loops", but I might express the benefits in at least a couple of ways; - reuse; the more general the interface, the more extreme the reuse, and the more intense the network effects, since more objects can be accessed with it - low coordination costs via the ability to bind an identifier to a an interface > How important is "partial specification" and "partial > understanding" in all this? I don't believe it matters at all to the binding issue. It just helps with integration. [1] http://lists.w3.org/Archives/Public/www-ws-arch/2003Jan/0099 MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
Received on Tuesday, 7 January 2003 00:09:28 UTC