Re: Draft Partitioning

At 09:30 AM 6/17/01 +0100, Brian McBride wrote:
> > But also, it has been suggested (by TimBL and others) that reification can
> > be a basis for defining extensions to the basic RDF semantics, such as
> > extension to full FOL.
>
>Yes, I've been trying to follow those discussions.  Would you say that
>consensus has been reached in that forum?

No... I think there are many reasonable viewpoints and no clear leader.

However, I think the case has been made very potently (by Pat and others) 
that triples alone are not sufficiently rich a syntax to capture all of the 
goals of RDF.

> >  Based on discussions in RDF-logic, I understand
> > this can only work if these new extensions have clear syntax extensions
> > w.r.t. the RDF core.  Which I think means that reification, if it is to be
> > used as a "hook" for such extensions, must itself have a distinguished
> > place in the syntax of RDF.
>
>When you say syntax extensions what are we talking about here?  There is an
>issue:
>
>   http://www.w3.org/2000/03/rdf-tracking/#rdfms-quoting
>
>which is about an extension to the RDF/XML syntax.  That is not something
>that affects the abstract syntax, yes?

I think that, and the contexts issue that it refers to, are all 
inter-related with the abstract syntax issue I am raising.

For what it's worth, my approach in this has been to try and identify a 
smallest set of changes that seem to satisfy the goals of RDF as I perceive 
them.  Not because this is inherently the best technical solution, but 
because the greater the change from current RDF, the harder I think it will 
be to build consensus.  (I would personally like to see an abstract syntax 
along the lines of something that Jonathan Borden has been suggesting, 
along with Pat Hayes and Drew McDermott, at 
<http://www.openhealth.org/RDF/RDFAbstractSyntax-20010611> -- I have some 
issues of detail with this, but that's another debate.)

>Reification can be represented as triples.  If that is all you are adding
>then the 'hook' you refer to is mere syntactic sugar.  I don't understand
>why syntactic sugar must have a distinguished place.

I don't think it is mere syntactic sugar.  I think it has to do with the 
way that semantics are related to syntax.  For example, the model theoretic 
semantics for DAML+OIL 
(<http://www.daml.org/2001/03/model-theoretic-semantics.html>) builds 
"higher level" syntactic constructs from collections of RDF triples for the 
purpose of assigning semantics.

Similarly, the early Scott/Strachey work on assigning denotational 
semantics to programming languages 
(<http://liinwww.ira.uka.de/cgi-bin/bibshow?e=Dpnqjmfs0Gvodujpobm/vojrvf%7d22:8324&r=bibtex&mode=intra>, 
<http://citeseer.nj.nec.com/context/28825/0> -- citations only, can't find 
an online copy) starts with an abstract syntax, and assigns semantic 
interpretation function to each of the productions of the syntax.  Thus, to 
this extent, the syntax has an important role in the specification of 
semantics, and needs to distincguish the cases to which different semantics 
must be applied.

(Maybe there are other ways to do this, but I think I've at least shown 
precedent for this approach.)

> > Otherwise, I think that any of these "extensions" to RDF must be completely
> > different languages that happen to have a passing resemblance with RDF
> > (i.e. we cannot be sure that expressions conforming to the core RDF syntax
> > still have the same meaning).
>
>That is what I call 'the Janet Argument'.  Actually, I'm quite confident
>that, given we do a good job of clarifying RDF 1.0, further work on RDF 2.0
>can extend RDF 1.0 is sensible way.

I don't know what you mean by "Janet argument".

In a discussion on RDF logic, Peter Patel-Schneider picked me up for 
ignoring the (obvious) fact that if an RDF triple has some semantic by 
virtue of the semantics assigned to _any_ triple, there is a difficulty 
raised when we wish to use a particular vocabulary item to have some 
different extension syntax.  All I am suggesting is that the hooks for 
consistent future extension are not closed off at this stage.

> > All this is predicated on the idea that reification is retained in
> > approximately its current form.
>
>There seems to be mixed views on that.  If we move it out of the core
>to a vocabulary, essentially we are letting the market decide.  Those
>folks who find it useful will use it.  Those who don't will not.  If
>it turns out that it is a good mechanism for building FOL expressions,
>then it can be used for that.  If, as frankly I think is much more
>likely, folks would rather have something akin to S-expressions, e.g.
>nested statements, for that purpose, then the RDF 2.0 team won't have
>reification getting in the way.

I have a concern that there is something fundamental that needs to be noted 
in the core design. (Some way of using statements without asserting them, I 
think.)  Anything beyond that I am happy to do as you suggest -- no, 
stronger than that, I really believe that we should try to leave as much as 
possible to extensions (but no more).

> > In any case, I think the RDF core should try to anticipate some ways in
> > which richer semantics can be introduced.
>
>We might be really agreeing here, or we might feel very differently.

I think we mostly agree.

If there's any debate, I think it is about what constitutes the minimum 
hooks for building all the things we want to be possible in the future.

>If we keep the core of RDF lean, mean and simple, we create
>maximum flexibility for the future.

I really do agree with that principle.

#g


------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<Graham.Klyne@Baltimore.com>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------

Received on Tuesday, 19 June 2001 07:16:13 UTC