Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: [xml-dev] Syntax versus Semantics (was: "vocabulary constraints"

From: "Cox, Bruce" <Bruce.Cox@-----.--->
To: "Dan Brickley" <danbri@------.--->, "Costello, Roger L."
Date: 3/2/2009 9:44:00 PM
RDF, or RDFS/OWL if you prefer, does no more than manipulate the labels
we use for concepts.  Machines don't check meaning, they check the
labels and their combinations based on the rules we've set.

But I don't agree with Roger's definitions, either.

If syntax can be checked by machine, why should it have to be
convenient?  Some long-standing mathematical conjectures have been
proven in the past few years solely by virtue of brute-force computation
impossible before today's machines were available.  Deep Blue as well
won by brute force against Kasparov (who, I'm told, said, "but Deep Blue
didn't *enjoy* winning").

I agree that "semantics" is overloaded and differently so in different
contexts.  There are those operations that 1) cannot be performed by
machine, there are those operations that 2) can but aren't performed by
machine (it isn't economical, or we haven't figured it out yet), and
there are those operations that 3) are performed by machines.  The
boundary between 2 and 3 is a territory in dispute with daily skirmishes
on several fronts where there are clear winners on one side or the
other, but with no end to the overall conflict in sight.  I think the
best we can expect is a certain equilibrium between what machines can
profitably perform and what humans will profitably perform (Len's social
contract).  The disputed territory moves across the landscape, but never
completely disappears.

Semantic web?  Tanks and very long guns ended trench warfare, but they
didn't end human conflict.  Every new technology that makes it possible
for some process to (at last) be performed by machine ultimately exacts
a toll on human behavior: we have to follow the rules as well.  If we
don't, the context that makes the machine processing possible and
comprehensible to humans is absent and the output the machine produces
fails to meet expectations.

When we first introduced XML for the detailed description of an
invention, even those few applicants who whole-heartedly adopted it
often failed to correctly populate certain key elements.  Now, the
description is submitted in PDF.  At least it isn't on paper.  In Japan,
on the other hand, XML in patent applications is a resounding success.
In this case, the difference is entirely cultural.

Bruce B Cox
Manager, Standards Development Division
USPTO/OCIO/SDMG
571-272-9004


-----Original Message-----
From: Dan Brickley [mailto:danbri@d...] 
Sent: Sunday, March 01, 2009 9:33 AM
To: Costello, Roger L.
Cc: 'xml-dev@l...'
Subject: Re: [xml-dev] Syntax versus Semantics (was: "vocabulary
constraints" and other constraints

On 1/3/09 14:03, Costello, Roger L. wrote:
> 1. If something is in the realm of "semantics" does that mean it can
only be processed by humans (eyeballs)? It cannot be processed by
machines?
[...]
> WHAT IS SEMANTICS?
>
> Something is semantics if it cannot be simply specified in a
declarative manner or it requires procedural code to express it.

Some aspects of meaning can be made quite readily machine-checkable.

If you say something is a Person, and if you use vocabulary in which 
Person and Document are disjoint classes, don't in the same breath 
ascribe properties to that thing which imply it is a Document. Machines 
can spot when you do this, even with simple RDFS+OWL schemas like FOAF. 
They can figure out, "hey, no true description of the world could ever 
fit this picture, what's up?".

If you are working with RDF (RDFS/OWL) content, and the only rules you 
have are RDFS schemas and OWL ontologies, then you're pretty much 
limited to this kind of checking. However there are many more ways of 
screwing up in data, whether or not in RDF(expressing falsehoods, being 
incoherent or unintelligible or boring or vague), beyond contradicting 
yourself. For RDF, we can build machine-friendly checkers for some of 
this directly top of the RDF/OWL layer either directly in a query 
language (eg. SPARQL) or indirectly by generating the SPARQL from OWL 
plus some unwritten assumptions.

Some trails back to 2001 here... and Schematron-inspired RDF work on 
expressing integrity constraints:

http://www.xml.com/pub/a/2001/02/07/schemarama.html
http://ilrt.org/discovery/2001/02/schemarama/
http://isegserv.itd.rl.ac.uk/schemarama/
http://danbri.org/words/2005/07/30/114
also
 
http://clarkparsia.com/weblog/2009/02/11/integrity-constraints-for-owl/
  http://jena.sourceforge.net/Eyeball/

Note than in RDFland, folk sometimes talk about its graph data model as 
a kind of abstract 'syntax'. Especially OWL people lately. I don't 
expect terminologies here to ever fully converge, too many compsci, 
engineering and other traditions are jumbled up together when they meet 
Web standards.

cheers,

Dan

--
http://danbri.org/


_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php



transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent