W3C home > Mailing lists > Public > www-rdf-interest@w3.org > January 2000

RE: Peering over the edge of the RDF cliff

From: Jeff Sussna <jeff.sussna@quokka.com>
Date: Wed, 5 Jan 2000 14:52:49 -0800
Message-ID: <E19A882C6CD5D211A8A70008C75B6AF40122CCEA@pcmail.quokka.com>
To: "'caro@Adobe.COM'" <caro@Adobe.COM>
Cc: "'www-rdf-interest@w3.org'" <www-rdf-interest@w3.org>
Actually, on rereading the formal RDF grammar, neither of our examples may
in fact be legal. The parseType="Resource" definition states that the
contents of the property element should be treated as the content of a
Description element. It does NOT state that the containing property should
match the Description production. In fact, that property just has a property
name like any other. So I think it looks more like:

	<Asset ID="foo.html">
		<author ID="authorOfFoo" parseType="Resource">
			<object resource="Fred"/>

If I am correct, this is even uglier than I had feared!


-----Original Message-----
From: Jeff Sussna 
Sent: Wednesday, January 05, 2000 2:24 PM
To: 'caro@Adobe.COM'; Jeff Sussna
Cc: 'www-rdf-interest@w3.org'
Subject: RE: Peering over the edge of the RDF cliff

I have not abandoned the RDF syntax. My example was legal RDF. I did
consider an abbreviation that is analogous to your example below, which
would look like:

	<Asset ID="foo.html">
		<Property ID="author">
			<object resource="Fred"/>

There are still two objects (foo.html and author), just one is embedded
inside the other. By the way, in your typednode example, you have a property
(author), and a subject (foo.html), but no object.

The one thing that is most definitely lost is any ability to do schema

-----Original Message-----
From: Perry A. Caro [mailto:caro@Adobe.COM]
Sent: Wednesday, January 05, 2000 12:59 PM
To: Jeff Sussna
Cc: 'www-rdf-interest@w3.org'
Subject: Re: Peering over the edge of the RDF cliff

Well, gee, if you're willing to abandon the syntax altogether, you won't
mind some hacks that are at least compatible with the RDF syntax, if not the

One option I've considered for this problem is to make the resource URL be a
literal, and then qualify the value to let people know that I really meant
it to be a resource:

<rdf:Description ...>
	<Property rdf:ID="author" rdf:parseType='Resource'>

Acutally, if you mean for Property to be a type, a typedNode might be

<Property rdf:ID="author" rdf:value="foo.html" valueType="resource"/>

This really makes your Property first class, and only creates one "object".

Another option is to use the parseType='Literal' escape-hatch and encode
whatever you want in the value:

<rdf:Description ...>
	<Property rdf:ID="author" rdf:parseType='Literal'>
		<subject resource='foo.html'/>
		<object resource='Fred'/>

This means that inferencing based on the pure unextended RDF model won't
work, but heck, it wouldn't work on your custom syntax anyway.  By hacking
the model but sticking with the RDF syntax, you at least maintain some
amount of interoperability.

Received on Wednesday, 5 January 2000 17:52:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:28 UTC