W3C home > Mailing lists > Public > www-webont-wg@w3.org > April 2002

RE: SEM: Layering

From: Smith, Michael K <michael.smith@eds.com>
Date: Mon, 29 Apr 2002 08:57:24 -0500
Message-ID: <B8E84F4D9F65D411803500508BE322140D6B5A41@USPLM207>
To: Jeremy Carroll <jjc@hplb.hpl.hp.com>, www-webont-wg@w3.org
Jeremy,

Re your response to

http://lists.w3.org/Archives/Public/www-webont-wg/2002Apr/0200.html

> I comment on whether <false> is a useful RDF graph, extending 
> the analysis.

There is a really low-level variance in viewpoint here, one that I have had
previously with other WG members.

When we talk about the syntax of OWL and RDF, I take that to mean the
grammar that defines the sentences that the semantics will provide a meaning
for.  The whole point of a syntax is to identify a subset the universal set
of character strings that we are willing to provide a semantic
interpretation for.

The abstract syntax is an abstract version of the same thing.   

You argue that:

> I see your first graph as having exactly the same status in 
> OWL as any other OWL contradictory graph: e.g.
> 
> a owl:differentIndividualFrom a .

I would argue that 

 x rdf:_1 a
 x rdf:_2 OWL:NIL
 x rdf:_3 b

is quite different from 

 a owl:differentIndividualFrom a 

The second is clearly an OWL statement (albeit translated to triple
notation).  Asking OWL to interpret the ill-formed OWL list with 'b' after
'OWL:NIL' is like asking the RDF semantics to provide an interpretation for 

 y rdf:type rdf:type z

This is not an RDF triple.  It has no interpretation in the RDF MT.  It is
simply not a statement in RDF.  Just as the list, '(a OWL:NIL b)' is not an
OWL syntactic component.  We can't say it in OWL.  And are thus not
obligated to try to provide a semantic interpretation for it.

> I think of these as simply false (in OWL). In terms of the 
> mappings T and TINV this is special. TINV of either of your 
> RDF graph above yields (owl)false. Then T((owl)false) is 
> (rdf)false. This is the only way of getting falsity in RDF, 
> by using a layer with the concept of contradiction.

Neither T nor TINV have anything to do with truth or falsity.  They take one
syntax to the other and back.  

> In terms of Mike's discussion of:
> 
> >SEMANTIC PROPERTY 1.
> 
> >  If RDF-ENTAILS(c,d) then OWL-ENTAILs(TINV(c),TINV(d))
> 
> and
> 
> >SEMANTIC PROPERTY 2.
> 
> >  If RDF-ENTAILS(T(a),d) then OWL-ENTAILS(a,TINV(d))
> 
> I think my analysis gives practically the same results, although I support
> (SP1) & (SP2) rather than just (SP2). The difference is in the cases where
> Mike's analysis does not allow (SP1) my analysis says TINV(c) = false, and
> (SP1) holds trivially.
>
> It's a different way of looking at it; quite probably not important.

In a previous message 

http://lists.w3.org/Archives/Public/www-webont-wg/2002Apr/0320.html

I gave a concrete example of why Semantic Property 1 cannot possibly hold if
we support one interpretation of dark elements.  So I would argue that there
is at least a potentially important difference here. 

I believe (without proof) that if TINV may in principle drop RDF information
that does not have an interpretation in OWL, that there will always be a way
to defeat Sematic Property 1.  Remember the high level language/Assembler
comparison.  In assembler we have information about where in memory values
are laid out.  We can say with certainty, given a particular memory layout,
that if we step past the end of the memory containing array A (by exceeding
the array size with an index) then we will overwrite the memory representing
B.  We could actually prove, in a language that did not guarantee array
bounds checks, that the assembler version of

 a[a.size] := 1

would set b to 1, assuming 0 based indices.  We cannot prove this at the
higher level, we don't have the information that we need.

- Mike

Michael K. Smith
EDS Austin Innovation Centre
98 San Jacinto, #500
Austin, TX 78701
512 404-6683
Received on Monday, 29 April 2002 09:59:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:57:49 GMT