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

RE: DTTF: high-level summary (attempt)

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Thu, 2 May 2002 20:29:49 +0100
To: "Massimo Marchiori" <massimo@w3.org>, <www-webont-wg@w3.org>
Message-ID: <JAEBJCLMIFLKLOJGMELDAEOPCDAA.jjc@hplb.hpl.hp.com>

> Is is true there's some weak consensus that, bad or good, we can
> try to leave RDFCore
> out, and work out the solution in WOWG? Or, is there still
> somebody saying he
> can't live with this? This is useful to do a first little step:
> let the semweb cg
> know that this dependency on RDFCore is discharged.

I could live with that.

> Secondarily, the base two points. I think there are two main
> issues boiling up
> in all the threads.
> a) One is Peter's point, about paradoxes and expressive power.
> b) One is Pat & Peter point, about semantic extensions.
> They are somehow related (b somehow subsumes a), yet can be
> usefully distinguished.
> a) essentially says, look, what we have is very powerful
> (essentially, graph
> construction), and we risk that the resulting language is not
> well defined
> (which implies, yes, a disaster).
> b) essentially says, there are big troubles in general, to do a semantic
> extension of RDF.
> Now, I think all the DTTFers are right (errr, is this a paradox?
> ;) when they
> claim respectively that a) and b) can't be solved with RDF as is
> (RDF: bad),

I am a long way from convinced of this.
The longer the discussion goes on, I find this basic claim to appear more
and more as a prejudice.

> and that a) and b) can in fact be solved.
> They are all right, because each starts from different
> assumptions, making
> their reasoning perfectly valid, and resulting in us clashing on
> the conclusions,
> rather then on the premises.

That's certainly true.

> Now, on a) and b), the personal viewpoint on "how it can be
> done" without
> changing RDF (so, the context).
> On a):
> + Yes, this is a big problem. but a way out is to define the
> semantics of OWL
> using graph rewriting (cf.
> http://lists.w3.org/Archives/Public/www-rdf-comments/2002AprJun/0018.html
> for a subset of a possible definition for RDF semantics). This
> can be seen as
> "considering the right syntax" (so, similar to Peter's
> syntactical constraints, only
> that the constraints are not on the graph, but on the rules used
> to extract
> the semantics).
> This works because it doesn't follow the "everything denotes",
> which is the understood
> assumption that, I think, is based on the RDF-cant-work-here
> argument (which is correct,
> under this assumption!).
> Onto on b):
> And, yes, this is related to the semantical extension problem. I
> think the understood
> assumption of the RDF-cant-work-argument has been that you have
> to model the semantics
> of an extension *using the same domain* (so, essentially like a
> semantical embedding).
> And under this assumption, yes, this is correct, RDF can't
> probably be used here
> (unless changing it with dark triples or similar).
> The way out here is to drop the assumption to use a semantical
> embedding: the domains
> of interpretations can be different. Doing so, we earn in
> flexibility of extension,
> and we lose something in semantic interoperability.
> I can provide extensive details on both a) and b) on demand, but
> before doing so (i.e.,
> debate on the correctness of a specific assumptions =>
> conclusions approach), it's way more
> important to notice the assumptions we come from. Under some
> assumption (that were natural
> and almost understood for me, but are likely not at all for
> others) there is a way out.
> Under others assumptions (reasonable as well, just different),
> there's likely no way out other than
> doing some heavy changes to RDF (personal view, but I do agree
> with Peter and Pat, once
> realized the context/assumptions they are reasoning in).
> Is this a fair high-level summary?
> -M

I do not feel that my point of view has been represented in it, so no;

Received on Thursday, 2 May 2002 15:29:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:04:30 UTC