Re: rdf as a base for other languages

Peter,
the substantive part of my response is toward the end of this message;  you 
may like to review that before responding to smaller points along the way...

At 08:49 AM 6/2/01 -0400, Peter F. Patel-Schneider wrote:
>From: Graham Klyne <GK@ninebynine.org>
>Subject: Re: rdf as a base for other languages
>Date: Sat, 02 Jun 2001 05:46:28 +0100
>
> > At 01:07 PM 6/1/01 -0400, Peter F. Patel-Schneider wrote:
[...]
> > >For example, suppose that you wanted to represent propositional formulae
> > >within RDF.  You might do something like:
> > >
> > ><rdf:type x OR>
> > ><component x y>
> > ><component x z>
> > >
> > ><rdf:type y rdf:Statement>
> > ><rdf:subject y John>
> > ><rdf:predicate y loves>
> > ><rdf:object y Mary>
> > >
> > ><rdf:type z rdf:Statement>
> > ><rdf:subject z John>
> > ><rdf:predicate z loves>
> > ><rdf:object z Susan>
> > >
> > ><loves Bill Susan>
> > >
> > ><rdf:type Bill Person>
> > ><rdf:type John Person>
> > ><rdf:type Susan Person>
> > ><rdf:type Mary Person>

[...]

> > My point:  why cannot the "extra" semantics be attached to a particular
> > value -- in this case, "OR"?
>
>Sure you can do this, but where would you stop?  In particular, if you
>wanted to have propositional or predicate logic, almost all information
>transmitted would use these special resources.  This, in my view, is no
>longer RDF.  Sure it uses RDF as a transfer mechanism, but just in the same
>way that it uses XML or unicode as a transfer mechanism.

Yes, I agree, it's no longer core RDF.

If the semantics of core RDF can be used in the new language, I'd say core 
RDF is providing more value than using XML or Unicode as a transfer mechanism.

> > [...]
> > >Sure, you can do anything you want outside of RDF.  However, if you want
> > >RDF to represent anything, you better do all your work within RDF.
> >
> > Why the insistence on all-or-nothing?  Is there any fundamental reason why
> > we cannot start with a language capable of expressing ground facts, and
> > extend it in a consistent way (creating a new language, "outside" the
> > original) such that the original language for expressing ground facts is
> > present as a sub-language?
>
>Because then you no longer have RDF.  Suppose we are talking about
>programming languages, and we decide that 360 Assembler is the way to go.
>A group of us, however, decide that we will add recursive functions (for the
>sake of argument let us assume that 360 Assembler does not have recursive
>functions, I think that this is the case but it has been so long since I
>programmed in 360 Assembler that I might be wrong).  Can we continue to
>call our language 360 Assembler and claim that 360 Assembler is now a more
>powerful language?

No, we can't, and I'm not trying to claim that we can.

>Similarly, there is no reason that you cannot have a language that can
>express ground facts, and embed it in a different language that can express
>more.  However, the meaning of this larger language is quite different from
>the meaning of the smaller language.  (Consider how you would handle
>``facts'' with variables in them---you can't just use the meaning from the
>smaller language, as it has no idea how to interpret the variables.)
>
>Further, even this is different from having a language for expressing
>ground facts (RDF), encoding more-complex constructs in this language, and
>using the ground facts language as the transfer mechanism.  Under this
>scheme, the encoding of the more-complex constructs are still viewed as
>ground facts, and end up becoming part of their meaning, which is not desired.

I agree.  I should have known better to ignore what at the time seemed to 
me like a small engineering detail, but which is really a gaping logical flaw.

I need to re-state more precisely my idea of core RDF as a sub-language of 
a more powerful logic language.

Let there be some set of URIs that are reserved from use in the core RDF 
language.  That is, no well formed core RDF expression may use these 
URIs.  (Leaving aside, for now, how such reserved URIs might be 
designated.)  These would be analogous to reserved words in programming 
languages like C or PASCAL.

Then, I would require that any RDF extension uses URIs from this reserved 
set for the purposes of introducing new semantics.  Thus, a statement in 
(say) RDF++ that depends on the particular semantics of RDF++ cannot be a 
valid statement in core RDF, so the semantic conflict you describe cannot 
occur.

I acknowledge that, logically speaking, this is a very different 
proposition from what has been discussed before.  But I think that in 
practical engineering terms it is a small change, relatively easily 
accommodated.

...

Returning to your example of 360 assembler.  There was indeed a 
"super-language" defined called (IIRC) PL/360.  I understand that it 
allowed PL/1-like control structures to be used in conjunction with 360 
assembler statements.  This language was clearly NOT 360 assembler.  But it 
allowed individual 360 assembler statements to be used in a more powerful 
programing language environment, providing virtually full access to the 
facilities (semantics?) of the underlying machine instruction set.

I remember similar techniques used in the early days of PDP-11 and VAX 
programming.  So there are historical examples of languages that use (most 
of) a simpler existing language as a subset.  Logically they were, as you 
argue, different languages;  but they also demonstrated great practical 
value (in their time) from re-use of (much of) an existing language.

#g


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

Received on Monday, 4 June 2001 17:44:20 UTC