Adam Pease wrote Thu, 07 Aug 2003 09:48:57 -0700:
> Peter,
> If the model is created in KIF and then translated to Protege this
> might work, but if the model is created in Protege and translated
to > KIF you'll have the problems I mentioned analogous to writing C
> style in C++. (01)
Sounds good. I was, in fact, looking forward to more discussion on
"how" we can end up with both KIF and Protégé. Therefore, what you
point out here is most relevant indeed. (02)
> It's good that Protege is familiar, and has a large user
> community, but that line of argument could be extended to XML.
> More people are familiar with XML. It has a larger user base
> and tool set, so why not just create XML rather than worry
> about ontologies?
&
> if the argument for a frame representation is that it has a larger
> user base, or more tools (which is the argument I believe that
> Peter was making), than that same argument could be made ad
> absurdum to argue for just sticking with XML, and not trying to
> create an ontology. (03)
I was using that argument to support my case that "Our solution will
need to be adopted and applied, if it were to even come close to being
successful", not to be confused with condoning that Protégé (or KIF,
or XML) is totally adequate, or optimal, on its own. (04)
My consideration extends beyond the ability to represent the knowledge
... and is supposed to cover diffusion, user acceptance, and other
user adoption related "soft" (social, psychological, ...) issues as well. (05)
As mentioned, we would need to
... "tackle both the science, as well as coming up with the
engineering solution that is "good enough" ..." (06)
I am sincerely hoping that we we can achieve the precision (as in the
"science") as well as being able to compromise, optimize, and DELIVER
a standard business ontology to the masses/industry (as in the
"engineering"). (07)
The approach to achieving one or the other may be different, but that
should not preclude us from considering both, and to make an honest
attempt to achieving both at the same time. It's going to be a
challenge ... but then, we've got some *very* good people in the
community too! :-) (08)
Regards,
PPY
-- (09)
Adam Pease wrote Thu, 07 Aug 2003 10:28:15 -0700:
> Kurt,
>
> At 10:18 AM 8/7/2003 -0700, Kurt Conrad wrote:
>
>> At 2003-08-07 09:48 -0700, Adam Pease wrote:
>>
>>> More people are familiar with XML. It has a larger user base and
>>> tool set, so why not just create XML rather than worry about ontologies?
>>
>>
>>
>> While I find this argument to be dismissive, it may point to the core
>> issues underlying the current debate.
>
>
> I didn't intend the comment to be dismissive. The point was that if the
> argument for a frame representation is that it has a larger user base,
> or more tools (which is the argument I believe that Peter was making),
> than that same argument could be made ad absurdum to argue for just
> sticking with XML, and not trying to create an ontology.
>
>> The question is not whether or not to create a XML representation.
>> That decision has been made (by another, larger group). The vast
>> majority of the work has been done. And the XML version will almost
>> certainly be ready before the fully-formalized ontological version.
>> Why, because more people are familiar with XML; it has a larger user
>> base and tool set; and -- perhaps more fundamentally -- it is an
>> appropriate fit for the targeted utilization scenarios.
>
>
> I agree
>
>> From my perspective, it seems clear that the "UBL ontology" will take
>> a variety of forms.
>
>
> I agree. In prior work that I've mentioned, I've created a formal
> ontology in logic and then extracted what can be expressed in a
> relational database.
>
>> Each representation will have relative strengths and weaknesses. In
>> sort, logical expressiveness is only one measure of value. Clearly,
>> the XML representation of UBL is well-optimized for some uses, but
>> weak -- or even inadequate -- for others.
>
>
> I agree
>
>> That was the basis for our decision to create a formalized ontology
>> based on the UBL concepts. What other representations should be
>> produced? I don't know.
>
>
>> While I can follow this discussion at a general level, I don't have a
>> sufficient grasp of the subtleties to have strong opinions regarding
>> ontological tools and languages. In fact, about the only bias that I
>> have is one of creeping incrementalism: Start your semantic
>> formalization simply, and add complexity and richness as your
>> requirements, understanding, and resources warrant it.
>>
>> From my vantage point, I'm seeing indications that a KIF
>> representation might not be the best fit for all usage and interaction
>> scenarios.
>
>
> I agree
>
>> This observation does not imply that a KIF representation should not
>> be produced, or even how and when. Rather, it suggests that to meet a
>> broad set of user requirements (perhaps, even, including the needs of
>> the Ontolog modeling community) work on KIF needs to be balanced with
>> work on other technology platforms.
>
>
> I don't see that that follows. The work can be done in logic, in order
> to have a deep analysis of the domain with formal axioms, and then less
> expressive versions can be extracted for different implementation.
>
>> I guess this leads me to a corollary question: Does the decision to
>> produce an ontology in KIF effectively preclude working with any other
>> languages and/or platforms?
>
>
> No, but I believe the reverse is at least partially true. If we choose
> to develop the ontology as a frame system, it will have to duplicate a
> lot of the content that already exists in SUMO, and then won't be
> transferable to a formal ontology in logic later.
>
>> If so, are the tradeoffs acceptable?
>>
>> Or, looking at it from the requirements side: What representations are
>> needed? Is KIF adequate to handle all of the expected utilization
>> scenarios?
>
>
> KIF (or more generally first order logic) will certainly not be the
> appropriate "object language" for many implementations, but it's the
> best language available for formalizing a domain.
>
> Adam
>
>> /s/ kwc 2003.08.07 10:17 (010)
Adam Pease wrote Thu, 07 Aug 2003 09:48:57 -0700:
> Peter,
> If the model is created in KIF and then translated to Protege this
> might work, but if the model is created in Protege and translated
to > KIF you'll have the problems I mentioned analogous to writing C
> style in C++.
> It's good that Protege is familiar, and has a large user
> community,
> but that line of argument could be extended to XML. More people are
> familiar with XML. It has a larger user base and tool set, so why
> not just create XML rather than worry about ontologies?
>
> Adam
>
> At 09:41 AM 8/7/2003 -0700, Peter P. Yim wrote:
>
>> I will not question the appropriateness of KIF, in terms of formality
>> and expressiveness. On the other hand, we have Protégé, a tool
>> familiar with, probably, by the most number of ontology practitioners
>> (albeit small as they are already) as substantiated by our own survey
>> (see:
>> http://ontolog.cim3.net/forum//ontolog-forum/2002-11/msg00035.html )
>> and Protégé's user statistics (see:
>>
http://purpleslurple.cim3.org/ps.php?theurl=http://protege.stanford.edu/#purp169 (011)
>> ).
>>
>> Referring, again, to both our [ontolog-forum] charter (see:
>> http://ontolog.cim3.net/cgi-bin/wiki.pl#nid011 ),
>> and that of UBL's (see:
>> http://www.oasis-open.org/committees/ubl/charter.php ),
>> we are out to contribute to solving an e-business industry
>> standardization problem. Our solution will need to be adopted and
>> applied, if it were to even come close to being successful.
>>
>> As such, I am in favor of having our work represented (at least) both
>> in KIF and in Protégé (I actually thought that was what we had agreed
>> upon before) -- with both being our normative deliverable. We need
>> to leverage the Protégé users, developers, plug-ins, ... etc.
>>
>> Therefore, my suggestion is that we should focus the conversation,
not
>> on whether its should be KIF or Protégé, but rather, how can we
>> deliver BOTH, and in so doing tackle both the science, as well as
>> coming up with the engineering solution that is "good enough" to
be an
>> applicable industry standard -- and, be able to help the industry
>> migrate to that solution with ease.
>>
>> Regards,
>> PPY
>>
>> P.S. May I request that we all try to make sure that the
discussion is
>> consistent with the subject line -- this will greatly facilitate
>> future retrieval/re-use of the knowledge, at least by humans. :-)
-ppy
>> -- (012)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Unsubscribe/Config:
http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (013)
|