ontology-summit
[Top] [All Lists]

Re: [ontology-summit] Clarification re Big Data Challenges Synthesis

To: ontology-summit@xxxxxxxxxxxxxxxx
From: John F Sowa <sowa@xxxxxxxxxxx>
Date: Fri, 06 Apr 2012 16:08:22 -0400
Message-id: <4F7F4D36.8050608@xxxxxxxxxxx>
On 4/6/2012 10:27 AM, doug foxvog wrote:
> I think the issue should be addressed.  Instead of simply deleting
> the passage, it should be replaced.    (01)

I agree that the issue is worth discussing.  But it's so complex that
it's hard to summarize in short bullet items.    (02)

> 3. Ontologies can be built to have both expressivity and scale.    (03)

There are some important distinctions hidden beneath that statement.
An ontology is a theory about what exists, but not every theory
is an ontology.  And a give ontology might consist of a huge number
of interrelated theories, microtheories, alternatives, and special
cases.    (04)

But even a very complex ontology might be used as a resource from
which many special cases can be derived.  As an example, consider
the way Andersen et al. extracted subtheories from Cyc.    (05)

Then after they extacted the subtheories, they performed many
kinds of transformations to adapt them to different computational
requirements and limitations for solving different kinds of problems.    (06)

Then there are the questions about who or what is going to do
those transformations and adaptations.  The SME?  The knowledge
engineer?  The user who has the problem?  A consultant hired
for that purpose?  Some tool(s) that are used by or triggered
by any of those people?  Anybody else?  Why?    (07)

> Although an ontology may be highly expressive, uses of that ontology
> need not calculate every statement that could be derived from the
> rules in the ontology and the data in the local knowledge base.    (08)

Are you talking about the ontology, a theory derived from it, or
an implemented program or system that is derived from a theory that
is derived from the ontology?    (09)

> Just because you CAN calculate something doesn’t mean you SHOULD
> calculate it. Stick to information that is strictly useful to building
> your big data application.    (010)

End users don't know anything about what is being calculated or why.
SMEs are experts in their subject, not in any kind of calculation.
Who or what is making those calculations?  Why?    (011)

> Computationally expensive rules need not forward chain.    (012)

An if-then statement has no implicit computation associated with it.
When it is used as a rule, the same statement can be used in many
different ways for different purposes to solve many different kinds
of problems.  The qualifier "computationally expensive" cannot be
applied to any if-the statement taken out of context.    (013)

> Backward chaining complex rules need not be computed in a knowledge
> repository.  Such calculations can be performed locally to answer
> questions and the results can be stored back into the repository.    (014)

Again, any talk about backward chaining is getting down to nitty
gritty computation that is many levels removed from the ontology.
Who are you talking about?  What is their purpose?    (015)

> There can be a lot of value just getting the data federated and
> semantically aligned.    (38GD)    (016)

I'll give a qualified yes to that point.  The major qualification
is that I have no idea what you are federating or why.  All of the
above qualifications apply.    (017)

John    (018)

_________________________________________________________________
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/     (019)
<Prev in Thread] Current Thread [Next in Thread>