W3C home > Mailing lists > Public > www-rdf-logic@w3.org > June 2001

[Fwd: rdf as a base for other languages]

From: Wolfram Conen <conen@gmx.de>
Date: Tue, 05 Jun 2001 15:24:27 +0200
Message-ID: <3B1CDD8B.5C6AEE0A@gmx.de>
To: phayes@ai.uwf.edu
CC: www-rdf-logic@w3.org
pat hayes wrote:
> 
> >
> >Once you start to "interpret" triples with a host formalism, you may
> >easily get rid of reification if you interpret it as nesting.
> 
> But how do you tell which reifications are to be interpreted as
> nesting and which are to be interpreted as reification? 
> Because reification, if understood as being, indeed, reification, 
> is not nesting. 
> That was the point of my reply to Sandro: what we need are
> ways to use subexpressions without mentioning them and without
> asserting them. "Nesting" is a good word for this.
> 

I took the following approach: lean back, Wolfram, relax, forget some
assumptions about the meaning of some words, read the RDF M&S document
and try to come up with a reasonable (workable?) interpretation. And I
haven't found too much in the spec that forbids to interpret that what
is being called "reification" in RDF M&S as nesting (and only as
nesting). I think that the understanding of reification that you mention
above, may certainly be useful but requires a proper notion of semantics
(while nesting helps to build expressions) - so, for me, it can be
tackled as soon as the "expression" layer is settled and we start to
talk about the details of semantics.

>
> > You "only" have to write useful mappings and axioms to deal with
> > this nesting.
> 
> In what language? If we had a language to write axioms and rules
> which could deal  with this stuff, all our problems would be solved.
> That is where we came in.
> 

My view was "pragmatic": we wanted to be able to express some semantics
"on
top of" RDF, to exchange this semantics, to change them if needed etc.
so that we could start building some "semantically-enhenced"
applications., so we took the following approach:
* view RDF M&S as allowing to formulate a set of 3-ary expressions.[With
"interpreting" reification as nesting (and, possibly, containers as
lists), it could also be transformed into a set of nested 3-ary
expressions (and lists)].
* map the 3-ary expressions to a predicate "triple" in Prolog 
* add a predicate "definedAs" to RDFS that allows to make
Prolog-definitions of properties explicit. Express the RDF Schema
concepts with rules in Prolog, and augment the Schema documents
accordingly.
* Add the mapping and the "definedAs" on top of Jan Wielemaker's RDF
Parser (SWI-Prolog) and start playing around with "little languages"
that are defined in RDF (Schema) documents based on an explicit and
accessible axiomatization of properties (for an implementation, see the
RDF Schema Explorer [1]).

We, then, were able to experiment with semantics of
properties/constraints, play around with alternatives, be explicit about
our intentions etc. without having to wait for a standardisation to come
to a conclusion and the subsequent development of stable tools that
implement the standardized semantics. Hm, maybe such an approach -- very
few and simple "built-ins", axioms accesible in the RDF Schema
documents, "truely" extensible on the grounds of the chosen host
formalism (plain Prolog in this case, though XSB with tabbling would
sometimes be better suited, for example to axiomatize subProperty) -- is
more practical then trying to define yet-another-general-purpose
language? I don't know.
Well, at least the RDF Schema explorer has already been helpful for
Reinhold's further development of XWMF and some access-control stuff, so
it seems to be a "workable" approach somehow, and it gives an enjoyable
freedom to adapt semantics to the requirements of the domain (in our
experience).

There is still a huge number of interesting questions: impact of
distributed, shared, partially accessible, "secured" "knowledge bases",
impact of out-dated, updated, deleted knowledge, etc. which all may
become interesting in a Web context, that will probably be more easily
discussible if a number of practical experiences with different
semantics in different domains have been made (for example, based on the
"host formalism" approach from above?).

If one would really want to have ONE "RDF-like" language only, why not
take OIL/DAM-L which seems to have what some people most urgently want:
a clean semantic (and forget about RDF Schema?)? [Not to be
misunderstood:
if RDF M&S would be cleanly seperated from schema constructs, would
precisely and unambigously define, how expressions (RDF models, ideally
with nesting/lists) have to be computed from the XML/RDF syntax, and if
we would start to standardize some mappings of RDF and axiomatizations
of RDF Schema to some host formalisms, I would prefer the "host
formalism" approach outlined above, because it gives the freedom to
adapt the axiomatization even to exotic requirements whenever the need
arises and is, still, in some sense, interoperable (and available)]. 

Best regards,
	Wolfram

[1] http://wonkituck.wi-inf.uni-essen.de/rdfs  
(newly updated paper available upon request)
Received on Tuesday, 5 June 2001 09:22:43 GMT

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