RE: Unasserted triples, Contexts and things that go bump in the night.

Original posting to RDF Core, this message also to Webont.

As I understand it, the minimal unasserted triple proposal is that at least
for daml:collection it would have been better if the triples with properties
daml:first and daml:rest (and maybe those ending rdf:type daml:List ), were
somehow special.

There is an intended syntactic restriction on these triples i.e. that each
cell in a daml:collection has:
- rdf:type daml:List (and no other)
- exactly one daml:first property (pointing to a resource)
- exactly one daml:rest property ( pointing to daml:nil or another cell )
- no other properties.

At least some of these restrictions could be described with Daml+Oil. That
approach is not compatible with unasserted triples.

Alternatively we need another language (maybe english) to describe these
restrictions.

My point being that using dark triples to construct purely syntactic
substructures within RDF graphs then begs the question of how to describe
the syntax of those syntactic substructures.

The various schema proposals appear to me to be a way of (indirectly)
constraining the syntax, and hence there is a win in terms of learning curve
if we don't need to duplicate at the metameta level what we are already
doing at the meta level.

I am deliberatly sidestepping whether we want daml:collection to become
owl:collection.

Jeremy

> -----Original Message-----
> From:  Pat Hayes
> Sent: 20 March 2002 07:52
> To: w3c-rdfcore-wg@w3.org
> Subject: Unasserted triples, Contexts and things that go bump in the
> night.
>
> 1. Introduction: why bother?
>
> RDF(S) is proposed to be a 'foundation layer' for the semantic web.
> Exactly what this means isn't entirely clear, but the Webont WG have
> in mind that 'higher' levels, involving more expressive languages, in
> particular the hypothetical OWL (1) should be semantic extensions of
> RDF, rather in the way that RDFS is, ie that one can get to the
> content of those higher levels by imposing extra semantic constraints
> on RDF syntax, and also (2) they should be implementable as RDF
> triples stores, so that any OWL assertion is syntactically legal RDF
> and can be processed by an RDF engine, even if said engine has no
> idea what it means in OWL.
>
> It turns out to be very tricky to satisfy both of these requirements
> at once, and may indeed be impossible if the requirements are given a
> very tight, strict interpretation. The problems, it is claimed, all
> arise from the oddities of RDF, and the 'blame' for these problems is
> widely perceived as being due to RDF's inherent peculiarities. These
> peculiarities include the free-wheeling nature of the graph syntax,
> which fails to conform to various kinds of 'regularity' which higher
> languages might wish to impose on syntax (eg no loops of property
> applications; only directed graph structures allowed in syntax; no
> properties of properties, etc.); the fact that class-membership in
> RDFS is a fully-fledged property (in contrast to many formal set
> theories which give the membership relation a special status to
> protect the system from the Russell paradox); and the fact that
> according to the model theory, all RDF triples make an assertion.
>
> This last point is the main problem (in my view, the only real
> problem). If RDF had a way to include triples in a graph which were
> not asserted (but were being used by OWL to encode the syntax of
> other assertions which had a meaning in OWL which diverged from the
> meaning that they would have if they were regarded as RDF assertions)
> then most, or maybe all, these difficulties of 'layering' could be
> avoided.
>
> 2. Dark triples.
>
> The simplest proposal is therefore to simply allow an RDF graph to
> contain triples which do not make any assertions. This allows such
> 'dark triples' to be used by other languages to encode syntax for
> more complex expressions (or indeed for any other purpose, as far as
> RDF is concerned.). The point of this is that RDF triples can be used
> both to make some simple assertions and also as a datastructure, but
> these two uses tend to trip over one another. Allowing datastructures
> to be sets of dark triples frees them from accidentally making
> assertions that are inappropriate to the intentions of the user of
> the datatstructure.
>
> This could be done in several ways. One idea is to allow an RDF graph
> to contain two kinds of triples, so triples need one extra bit. We
> could encode this in N-triples by having two ways to terminate a
> triple, so that
>
> ex:judy ex:age ex:whatever .
>
> is an asserted triple but
>
> ex:judy ex:age ex:whatever ;
>
> is an unasserted triple.

[..snip..]

Received on Wednesday, 20 March 2002 08:40:41 UTC