W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > June 2001

Re: Model-specific identity for anon resources, and its representation: A new issue?

From: Jan Grant <Jan.Grant@bristol.ac.uk>
Date: Wed, 27 Jun 2001 10:17:42 +0100 (BST)
To: Aaron Swartz <me@aaronsw.com>
cc: w3c-rdfcore-wg <w3c-rdfcore-wg@w3.org>
Message-ID: <Pine.GSO.4.31.0106271011240.19796-100000@mail.ilrt.bris.ac.uk>
On Tue, 26 Jun 2001, Aaron Swartz wrote:

> On Tuesday, June 26, 2001, at 04:06  AM, Jan Grant wrote:
> >>> Not really, no. You _still_ are going to need anonymous resource
> >>> resolution/unification in there somewhere: for example, if you decide
> >>> that two documents (or the same documentat two different URLs) are
> >>> talking about the same things.
> >> Sure, of course you are. I just want to move this out of the
> >> core level to something higher. This simplifies the core for
> >> those who don't need these things, and leaves it available for
> >> those who do.
> > Just don't use anon resources if you don't want them.
> Err, I don't follow. If I'm writing an application that accepts
> arbitrary RDF (which I am), I still need to deal with them
> somehow as long as they are in the abstract syntax. With my
> proposal, I could just ignore their anonymity if I wanted.

Avoiding an onerous implementation burden by winnowing the spec is not
something we get the opportunity to do very often :-)

I feel much the same way about the potential of stating equivalence
between two resources being written in to a level I can't just ignore.

Handling anonymous resources is tricky, but it's not too tricky.
Some brief notes about it here:
...although these are a bit old now, and deal with the impact on an
imperative API (as opposed, ferinstance, to anything prolog-based)


jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287163 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk
Prolog in JavaScript: http://tribble.ilrt.bris.ac.uk/~cmjg/logic/prolog-latest
Received on Wednesday, 27 June 2001 05:19:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:02 UTC