ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Fwd: Breaking News: Google supports GoodRelations

To: ontolog-forum@xxxxxxxxxxxxxxxx
From: "John F. Sowa" <sowa@xxxxxxxxxxx>
Date: Sun, 07 Nov 2010 10:58:37 -0500
Message-id: <4CD6CCAD.6060802@xxxxxxxxxxx>
Martin and Alex,    (01)

First, I'd like to say that the GoodRelations specification that Alex
cited is much better designed than most OWL ontologies I have seen:    (02)

    http://www.heppnetz.de/ontologies/goodrelations/v1.owl    (03)

MH:
> Note that the UML diagram is just an approximation of the formal
> account of GoodRelations.    (04)

Yes, I noticed that point.  But I didn't understand why you used the
word 'approximation'.  Is the UML version a subset?  Or is it actually
inconsistent with the OWL version?  If it's a subset, then I recommend
UML for the normative statement.  (UML has been defined in Common
Logic.  That makes it just as formal as OWL, but far more readable.)    (05)

A cleaned-up notation for OWL (i.e., one that dumps the XML brackets)
could be used for details not captured by the UML diagram.  An even
better solution is to design a version of controlled English to specify
those details.  The combination of UML + controlled English could be
compiled into the current version of OWL, if anybody wanted that.    (06)

But the fatal flaw that has plagued the Semantic Web from the beginning
was the decision to make the XML serialization the normative version.    (07)

I realize that there are often good reasons for embedding isolated
RDF triples in a document and even better reasons for RDFa tags.
But I would love to see examples where anybody found it useful
to embed isolated OWL statements in any document.    (08)

As just a tiny example of the fatal flaw, look the following comment:    (09)

    <rdfs:label xml:lang="en">WarrantyScope</rdfs:label>    (010)

A single comment, embedded in a document by itself, might require that
amount of detail.  But in every language designed for both computer
efficiency and human readability, such declarations are stated once
at the top and *never* repeated again.    (011)

The file for the GoodRelations ontology takes 1862 lines (126K bytes).
A good language could define the 37 classes in a tenth of that size.
There is no excuse for the unreadable and inefficient bloat.    (012)

> The reason that eClassOWl is so big is that it is the aim of properly
> representing a standard of 30,000 classes and 5,000 properties in OWL DL.    (013)

Cyc has 600,000 concepts.  I'm sure that a comprehensive ontology for
business and finance would require that many.  Multiplying the eClassOWL
specification by 20 would produce terabytes of OWL.    (014)

> While the constraints of OWL blow up the size of the specification a
> little bit, the main reason for the size of the ontology is the size
> of the underlying standard.    (015)

A factor of 10 is not "a little bit".    (016)

> As for syntax, note that GoodRelations data can be expressed using a
> variety of syntactical forms, including OData, JSON-LD, etc. see
>
>     http://www.ebusiness-unibw.org/wiki/Syntaxes4GoodRelations    (017)

Nobody designs multiple alternatives for a good notation.  This
multiplicity is a sign that the current situation is untenable.    (018)

> ... given that GoodRelations is a *Web* ontology I currently
> don't see the real benefit; at least it's not a priority.    (019)

The most successful *Web* language is JavaScript, which no sane
developer would ever serialize in XML.    (020)

Bottom line:  It's time for a serious rethinking of the SW strategy.    (021)

John    (022)

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (023)

<Prev in Thread] Current Thread [Next in Thread>