[Ontology Sharing][Fwd: Sharing]

["Chiusano Joseph" <chiusano_joseph@bah.com>]

The e-mail below is from a semi-recent thread on W3C-SWS-IG whose main
topic was cross-ontologies reasoning. The poster below brings up the
very important aspect of sharing of ontologies between organizations.

If there's anything that we can do in our SCM work to address the social
challenges associated with ontology sharing (whether it be registry
features or something in a spec) I think it would be great.

Thanks,
Joe

-------- Original Message --------
Subject: Sharing
Resent-Date: Wed, 24 Dec 2003 13:29:49 -0500 (EST)
Resent-From: public-sws-ig@w3.org
Date: Wed, 24 Dec 2003 10:27:35 -0800
From: Francis McCabe <fgm@fla.fujitsu.com>
To: public-sws-ig@w3.org
References: <EDDE2977F3D216428E903370E3EBDDC9032B89F6@MAIL01.stc.com>


I renamed this thread as the topic had drifted somewhat...

Sharing *is* related to ownership... so I have a dilemma for y'all at 
this Christmas.

If  building ontologies is hard work, (which it is by all accounts), 
then I wont do it unless I can see a benefit.

Pat assumed that it is a developers interest to share ontologies 
maximally, as that is the way that people benefit; but I want to offer 
a counter:

If I am a large customer (how about the largest customer in the world 
for a start) then it *is* in my interest to ensure that my suppliers 
are on board with me by using the same ontology. Vice-versa of course 
for large vendors.

However, it is definitely *not* in my interest to help my competitors. 
So, I will want to shut them out of the benefits of my hard work.

One way to do this is by differential licencing: I make it easy for my 
partners to licence my stuff and hard for my competitors to do so.

If you think this cannot happen, consider the situation in a sister 
organization wrt orchestration :). The differential licencing situation 
is potentially so severe in that case that I strongly recommend my 
employer to steer well away.

Now, what is the most productive stance to take on this? Should we 
throw up our hands in horror and bemoan the power of monopolies? Or 
should we embrace it; as a way of harnessing a powerful force for 
progressing interoperability across organizations?

Frank

P.S. To paraphrase Churchill:

young(X) & !socialist(X) => ! have_heart(X).
old(X) & !tory(X) => !have_head(X).


On Dec 24, 2003, at 9:49 AM, Ugo Corda wrote:

>
> Also, let's not forget that obstacles to code sharing are not only of 
> a technical nature. There are also all kinds of social implications as 
> well, related for example to personal satisfaction ("I prefer to write 
> my own code because I have a lot of fun doing that"), to political 
> reasons ("the code a write gives power to myself/my organization/my 
> company, and I am not going to give it away like that"), fear of 
> personal exposure ("God knows what kind of bugs are in my code - I 
> don't want everybody else to find out"), etc. As a personal anecdote, 
> I still remember the reaction of a development manager at a large 
> corporation when he was asked to share his organization's code with 
> other organizations within the same company: "I would not share my 
> code even with my mother".
>
> It will be interesting to see if and in which measure this kind of 
> social aspects will affect ontology sharing.
>
> Ugo
>
>> -----Original Message-----
>> From: Bijan Parsia [mailto:bparsia@isr.umd.edu]
>> Sent: Wednesday, December 24, 2003 7:24 AM
>> To: Graham Klyne
>> Cc: Ugo Corda; public-sws-ig@w3.org
>> Subject: Re: Cross-ontologies reasoning
>>
>>
>> On Dec 24, 2003, at 6:00 AM, Graham Klyne wrote:
>>
>>> At 18:21 20/12/03 -0500, Bijan Parsia wrote:
>>>> Interesting, code sharing exactly occurred to me as a
>> relevant thing
>>>> to consider.
>>>
>>> I don't know if this is a useful perspective, but I've noticed that
>>> code sharing seems to be much easier when programming in Haskell
>>> compared with (say) Java or C.  I find I can generally pick up
>>> third-party functions and just use them, more easily than with more
>>> conventional programming languages.
>>
>> Yes, the advantages of, oh, referential transparency had
>> occured to me.
>>
>>> I can imagine two possible contributors to this effect:
>>>
>>> (a) ultimately, many Haskell expressions are just values,
>> so in some
>>> respects they're closer to data than to code.  There isn't a
>>> procedural aspect to get in the way (e.g. no need to coordinate
>>> passage through the "von Neumann bottleneck"? cf. [1])
>>>
>>> (b) the type system (being highly polymorphic, having much
>> in common
>>> with ML and friends) permits, even encourages, typing
>> details that are
>>> not relevant to some function to be left unspecified.
>>>
>>> I'm not sure if this has anything to say about ontology sharing.
>>> Maybe that reducing assumptions made by any given ontology makes it
>>> easier to share?  (Hmmm... that sounds almost obvious.)
>>
>> There are two issues (at least) with code sharing: Getting enough
>> adoption so there's lots of code to share, and then making it
>> relatively painless to share.
>>
>> There is a lot of *some* kind of code sharing going on . Take Java as
>> one example.
>>
>> OWL like ontologies seem way closer to data sharing. Rules do
>> get quite
>> close to code sharing. Whether this is a difference that makes a
>> difference is the question.
>>
>> Interestingly, of course, that expression (or code) as values
>> seems to
>> push code sharing toward data sharing.
>>
>> (Note, lest anyone mistake me: I think the data sharing problem to be
>> highly non-trivial :))
>>
>> Cheers,
>> Bijan Parsia.
>>
>>
>