RE: "asserted triple" weasle-words must go [was: best way to write triples?]

At 02:27 PM 4/18/02 +0100, Jeremy Carroll wrote:
>In DAML+OIL the syntax of the language is encoded *within* the model rather
>than external to the model and merely interpreted in the semantics.
>
>We see this too in RDFS consider:
>
>A:
><my:range> <rdfs:subPropertyOf> <rdfs:range> .
><eg:foo> <my:range> <eg:bar> .
><a> <eg:foo> <b> .
>
>The triples both map into the model, then within the model an RDFS
>interpretation is constrained to understand the implicit triple "<eg:foo>
><rdfs:range> <eg:bar> ." and then that in turn constrains the interpretation
>of the explicit triple "<a> <eg:foo> <b> ."
>If we treated RDFS as merely a syntactic carrier then the fact that there
>are not explicit <rdfs:range> triples in the original graph (A) means that
>there are no range constraints to consider.

In this case, I think its relatively easy to see (even prove) that it is 
still possible to find interpretations that satisfy the constraints, and 
support the required entailments.

>On WebOnt, Pat and Peter have both asserted that we need to use the RDF
>graph as the syntactic carrier and not have such syntax reflected in the
>model.

But, consider I'll an example of 2-member set equality based on DAML style 
collections:

   A    rdf:type set .
   A    contains _:a1 .
   _:a1 first m1 .
   _:a1 rest _:a2 .
   _:a2 first m2 .
   _:a2 rest nil .

   B    rdf:type set .
   B    contains _:a1 .
   _:b1 first m2 .
   _:b1 rest _:b2 .
   _:b2 first m1 .
   _:b2 rest nil .

Here, first and rest are properties with relational extensions that have to 
satisfy whatever constraints we may need to lay down.  So we have:

   IEXT(I(first) contains { <_:a1,m1> <_:a2,m2> <_:b1,m2> <_:b2,m1> }
   IEXT(I(rest)  contains { <_:a1,_:a2> <_:a2,nil> <_:b1,_:b2> <_:b2,nil> }

Furthermore, in this case, to describe A and B as sets, they have the same 
members and are hence the same set, so anything true of one should also be 
true of the other.  This would lead to constraints like:

   forall (x) : <I(A),y> in IEXT(x) <=> <I(B),y> in IEXT(x)
   forall (x) : <y,I(A)> in IEXT(x) <=> <y,I(B)> in IEXT(x)

Now, maybe it is possible to find interpretations that satisfy all these 
constraints.  It's not clear to me that such interpretations 
exist.  Further, if they do, it's not clear that they would be sufficiently 
unconstrained to allow other useful constraints to be satisfied.

So it seems to me that even if it's not absolutely theoretically necessary, 
the detailed semantics of first, rest seem to be rather 
uninteresting.  Thus I think there is utility in being able to place 
certain parts of the structure "outside" the model theoretic determination 
of truth, so theorists can focus on the elements whose semantics are of 
interest.

Personally, I find the dark triples approach to language layering to be 
not-pretty, but I think can see that it does overcome some 
difficulties.  (I still like the idea of subgraphs-as-nodes: it seems more 
directly useful, but I suppose it also presents greater challenges to 
implementation in an RDF triple-store.)

>... I would like to see
>examples where this is not possible (ideally in-charter examples).

Because we're talking about a base for extension of RDF, I think in-charter 
examples will be hard to find.

>In practice, nothing will stop people who want to treat the RDF graph
>independently of its model theoretic semantics. However, *we* should, IMO,
>not be licensing or encouraging such behaviour unless we believe it to be
>advantageous.

Ha!  Maybe that's the rub?  If there's a clear way to experiment with RDF 
without breaking the semantics, people may prefer to do that.  If there is 
none, then people will go ahead and break the syntax and/or semantics 
anyway.  Isn't that exactly what happened with TimBL's N3?   (Except, at 
the time, there was no semantics to break.)

>I believe that such behaviour is disadvantageous, because it will mean the
>extension mechansim available in RDFS, such as rdfs:subPropertyOf are only
>applicable when people are using the model theory and not otherwise. Thus
>these extension mechanisms will become a source of confusion, and fall into
>disrepute. RDF document authors will need to know whether or not their
>application is using asserted or unasserted triples.
>
>The weasle words turn a normative specification into non-normative advice,
>because anyone who doesn't like Pat's excellent work can simply say, "Ah,
>but my graph isn't asserted"

So the dark triples approach, as I understand it, is to be more precise 
about indicating unambiguously in some way which triples in a graph are 
asserted.

#g


-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Thursday, 18 April 2002 12:43:10 UTC