Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

SUO: RE: AW: Resolution of Ballot Comments




Pierre,  

	Thanks for your reply to one of the concerns I raised in my vote.  I
have a follow-up comment below.  Note that I've edited out all of the stuff
in the original message that was relevant to other people's concerns.

Thanks,
Ian

> -----Original Message-----
> From: Pierre Grenon [mailto:pierre.grenon@ifomis.uni-leipzig.de]
> Sent: Tuesday, June 25, 2002 3:14 AM
> To: jim.s3@juno.com; standard-upper-ontology@ieee.org
> Subject: SUO: AW: Resolution of Ballot Comments
> 
> 2- Correct me if I'm wrong but if a starter document is 
> submitted to this
> group and this group decides to start working on the 
> material, this group
> will possess a basis on which to work, pruning and expanding 
> or merging a
> volo. If anything is added to the ontology in a future 
> OpenCyc release, the
> material would stand as natural candidate for integration to 
> the SUO WG
> corresponding fragment. But that would be to the entire 
> discretion of this
> group. How could it be otherwise?

The problem is that we could easily have two inconsistent "OpenCyc" paths of
development.  One would be the starter document accepted by the group
(assuming the vote eventually passes), with any additions/modifications that
were recommended by the group.  The other path of development would be the
initial release of "OpenCyc" together with successive chunks of content from
"full Cyc" that Cycorp incorporates into the public release of the ontology.
Having these two independent paths of development for a single ontology that
is in the running for a standard seems to me to unecessarily complicate
things.  If we could get a letter from Cycorp expressing the conditions
under which content additions/modifications recommended by the SUO WG would
be incorporated into OpenCyc, then I think we could have a single path of
development and a single cohesive proposal for a standard.  If we can't get
such a letter from Cycorp, then the group will have no control over the
successive versions of OpenCyc released by Cycorp and I don't see that it
makes sense for the group to approve OpenCyc as a starter document.

> 
> >
> > 2. Ian Niles raised the issue of 'control of the document,' 
> which gets
> > down
> > to copyright.  I will summarize where we stand at this 
> point, but give me
> > a few days.
> >
> >
> >   =====Ballot comments: (Please post any additional comments to the
> 
> > =====================
> >        I vote NO on the ballot question below for two 
> reasons.  First, as
> > many on the list have pointed out, OpenCyc needs to be 
> cleanly separated
> > from CycL and CycML.  Second, it's not clear to me that the 
> SUO WG would
> > have sufficient control over the development of extensions to and
> > modifications of OpenCyc content.  As I understand it, 
> Cycorp intends to
> > eventually move over a large amount of content in full Cyc 
> to OpenCyc.
> > However, it is possible that some of this content will be 
> rejected by the
> > group or that the group will recommend changes to content 
> that is already
> > part of OpenCyc.  In these two cases, it is not clear to me 
> that Cycorp
> > would be willing to acquiesce to the will of the group.  If 
> Cycorp is
> > willing to surrender control of the document to the group, 
> there should,
> > I
> > think, be a formal statement to that effect from the company.
> >
> > -Ian Niles
> > iniles@teknowledge.com
> > =======================
>