This is all good stuff, and I agree with John, but I fear we are slipping into
general language discussions rather than talking about use cases for large
systems in various domains. (01)
However, all this will of course also be captured. (02)
- Steve (03)
On Jan 22, 2012, at 10:22 AM, "John F. Sowa" <sowa@xxxxxxxxxxx> wrote: (04)
> Jack, Deb, Mills, Joe, and Toby,
>
> This thread spans the range from the sublime to the ridiculous.
>
> The sublime:
>
> JP
>> ... the boundary that separates machines from organisms.
>>
>> That boundary is the same one that frequently emerges in conversations
>> that pit "reductionism" against holistic thinking.
>
> DM
>> That plus what should be processed by machines versus thought through by
>people
>
> MD
>> Integral Ecology — Uniting Perspectives on the Natural World,
>> an 800-page tour-de-force by Esbjörn-Hargens and Zimmerman.
>> My sense is that there is a breakthrough waiting to happen here.
>
> The ridiculous:
>
> DM
>> I think we need to encode the standard hierarchy (from world
>> to a bolt on a piece of equipment) in RDF plus OWL.
>
> I agree with everything up to the last three words.
>
> If the Semantic Webbers had done their duty a dozen years ago, we
> wouldn't need all the preaching about how useful ontology could be.
> But instead of focusing on semantics, they got bogged down in syntax.
>
> The major web companies -- Google, Microsoft, Yahoo!, Amazon --
> have rejected RDF and OWL. They'll accept input in RDF, but they
> don't generate it, use it, or recommend it. If I were investing
> my own money, I would not bet on RDF + OWL.
>
> DM
>> I have a couple sample problems but want to get "the idealized
>> existing universe" in perspective first. For example, more precision
>> is needed for location from lat/long to navigating a floor (aka storey)
>> to a room, to a piece of equipment or sensor - then back out again
>> to the block, neighborhood, state with corresponding application domains
>> similar to places and spaces mapping science maps
>
> You can represent simple data in triples, but OWL is too weak to do
> the kind of reasoning required to support the above requirements.
>
> If you look at the overwhelming majority of OWL ontologies on the web,
> you'll find that they don't use anything beyond Aristotle. The biggest
> difference is that Aristotle's notation was much better -- for both
> people *and* computers.
>
> JSON is much more widely used than RDF because it has more structure,
> better typing, and a notation that is far more efficient for computers
> and far more readable for humans. Any JSON triples can be extended
> to n-tuples, they can have optional typing, they can be nested at any
> depth to form lists, and they have a simple mapping to most programming
> languages and most notations for first-order logic. JSON is also used
> and recommended by Google, Microsoft, and Yahoo! -- they have more
> power, more money, and more experience than the W3C. I'll bet on them.
>
> MD
>> Who is it that thinks that separate formalisms and tooling for semantic
>> web description logic, procedurally sequenced process models, and
>> aggregations of business rules provide an adequate conceptual framework
>> for, let alone a practical methodological foundation for
>> architecture/engineering/construction?
>
> I strongly agree with the implications of that rhetorical question.
> Among them is the need for common semantics.
>
> Commercial compilers became available in the mid 1950s. By the mid
> 1960s, compiler technology was mature. Today, we have commercial and
> open-source compilers that can take multiple programming languages as
> input and generate multiple machine languages as output.
>
> GCC, for example, can compile 7 programming languages as standard and
> another 8 or 9, but not in the standard version. For output, GCC can
> generate machine code for 20 major architectures, another 23 less
> popular architectures, and 20 more that are processed by specialized
> versions of GCC.
>
> Furthermore, anybody who designs a new programming language or
> a new machine architecture (hardware or virtual) can modify the
> GCC source code to support it.
>
> This means that syntax is a *solved problem* -- any and every syntax
> that anybody finds useful (including RDF + OWL) can and should be
> supported. But every syntax has a different "sweet spot". It is
> foolish to force everybody to use the same syntax for all purposes.
>
> Joe S
>> Formal concept analysis (FCA) may then be directly applied.
>> http://en.wikipedia.org/wiki/Formal_concept_analysis
>>
>> There are aspects of formal concept analysis and lattice theory
>> that may be applied across an wide range of topics using relations
>> as one guiding filter.
>
> I strongly agree. FCA is a semantic technology that is independent
> of any notation. It has been used successfully in conjunction with
> RDF and OWL. But it has also been used with a wide variety of other
> notations, logics, and programming languages.
>
> FCA avoids getting bogged down in battles about syntax. It is not
> rich enough to support all requirements for reasoning, but it
> supports a large subset of OWL by *automatically* generating the
> hierarchy of concepts (AKA classes) without requiring somebody
> to do the detailed coding in OWL. I'll bet on FCA.
>
> The critical issue is semantics. For GCC, the semantics is defined
> by an abstract machine. All source languages are compiled to an
> Interlingua that corresponds to that machine. All target languages
> are generated from that Interlingua.
>
> For logic, the ISO 24707 standard for Common Logic was designed as
> an Interlingua. DoD funded the IKRIS project, which recommended
> one additional feature to CL for the IKL language. The IKRIS
> project also demonstrated that IKL could serve as an Interlingua
> among several very rich knowledge representation languages,
> including CycL, which is the language used for the biggest formal
> ontology ever implemented and used.
>
> RDF and OWL are small subsets of Common Logic, with some built-in
> ontology that is easy to define in CL. JSON, predicate calculus,
> and many other common notations are also simple subsets.
>
> But I am *not* claiming that CL or IKL is an absolute requirement.
> What I am saying is that a common semantics is required. If anybody
> finds or defines a semantics that is better suited than CL or IKL,
> I would be delighted to support it.
>
> The first priority is a common semantics. The second priority
> is to evaluate proposals. CL is an example. The IKRIS committee
> recommended CL with one extension for IKL. If anybody has a better
> suggestion -- either a replacement or a modification to CL or IKL
> -- then we should consider it.
>
> TC
>> There are efforts underway to standardize the application of
>> ws-calendar schedules to mission functions (i.e. material
>> in the Program phase) to understand not just how much energy
>> will be required, but when.
>
> That's a typical application. And most application domains have
> traditional notations that the users and developers prefer. It
> is counterproductive to force people to shoe-horn their preferred
> notations to something like RDF and OWL. Instead, their notations
> should be compiled directly to the common semantics.
>
> The Cyc project has over 27 years of experience in translating
> input from a wide variety of different notations to CycL. That
> experience is valuable, and most of it is documented in white
> papers on the cyc.com web site. We should take advantage of it.
>
> I would also recommend the dissertation by Tara Athan, who used
> the IKL semantics to support knowledge interchange with the
> Geography Markup Language (GML). See the abstract below.
>
> John
> __________________________________________________________________
>
> Source:
> http://ruleml.org/papers/AthanDissertation/AthanGISDissertation2011.pdf
>
> XCLX: An XML-based Common Logic eXtension
> with Embedded Geography Markup Language
>
> Mary E. Athan
>
> A novel eXtensible Markup Language (XML)-based Common Logic eXtension,
> called XCLX, is presented. The novel syntax draws from the standard
> syntaxes Common Logic Interchange Format (CLIF) and eXtended Common
> Logic Markup Language (XCL), as well as Rule Markup Language (RuleML),
> Interoperable Knowledge representation Language (IKL), IKRIS Context
> Language (ICL), and XML Inclusions (XInclude). In addition, the syntax
> is open to user extensions, including embedding elements from foreign
> namespaces as names, functions and atomic sentences, and has a meta-
> language for self-extensibility. These features allow Common Logic to
> embed structured data, such as Geography Markup Language (GML), while
> maintaining a well-defined semantics. The overall syntax is defined
> by a modular schema, using a design pattern developed for RuleML.
> The XCLX semantics is defined either by formal mappings into equivalent
> syntactic forms (in XCLX or foreign dialects, including CLIF, IKL,
> ICL), or axiomatically through the meta-language. The semantics of
> the meta-language is novel and is stated directly. A number of
> illustrative examples, drawn from geography and GML, are presented.
>
> _________________________________________________________________
> 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)
|