Well, then, this panel may produce useful results if we examine the other
aspects of Christopher's view. (01)
If an ontology is an algorithm (however large in extent, variety and ambiguity)
then the artifact expressing the ontology must be modularized and
orchestration-enabled. This makes the design of the artifact a systemist's
challenge to rationalize both the semiotic (content) and the architectural
(structural) issues. (02)
The Semantic Web effort seems to have missed this point. (03)
On Jan 29, 2012, at 4:36 AM, Christopher Spottiswoode wrote: (04)
> Joe, Anatoly,
>
> You both make very useful points. Here I highlight just 2 of them:
>
> AL:
>> This ontologizing-in-the-large lead to your need to define not only
>> ontology-as-algorithm but also communication protocol between ontology
>> components that reside in different nodes. I doubt that mantra about
>> "federation" is helpful here. If you have web programming (that is in
>> essence programming-in-the-large) you speak not about "federating" of
>> web-server, load balancer, database, web-page generation, ad banner
>> importing, etc. but have another engineering approach (while all that
>> software developed by different organizations and reside on different
>> computers).
>
> As I shall be describing in some detail later, appropriate architecture
> leads to good 'Separation of Concerns', hence reliable and flexible
> application modularity while also enhancing the various other qualities
> usually sought. That is what a properly ontology-based architecture
> should of course produce, and "federation" is a good word to describe
> the result at the in-the-large level.
>
> In contrast to what I shall be describing, the conventional web
> programming you highlight is complication-inducing rather than
> complexity-respecting
>
> JS:
>> I suggest that the "binding force" or "binding concept" that forms a
>> number of items in to one entity is a key feature.
>
> Yes! That is indeed most strongly the case in the architecture I shall
> be describing (or trying once again to describe, lessons hopefully
> having been learnt...).
>
> All of which recalls that now very mainstream IS programming precept:
> Larry Constantine's "high module cohesion with loose module coupling".
> We don't have to reinvent that wheel.
>
>> Have fun,
>>
>> Joe
>
> Yes thanks, Joe, we sure will!
>
> Christopher
>
>
>
>
> _________________________________________________________________
> Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
> Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
> Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> Community Files: http://ontolog.cim3.net/file/work/OntologySummit2012/
> Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2012
> Community Portal: http://ontolog.cim3.net/wiki/ (05)
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2012/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2012
Community Portal: http://ontolog.cim3.net/wiki/ (06)
|