W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2004

Re: identity management use case

From: Dirk-Willem van Gulik <dirkx@webweaving.org>
Date: Thu, 26 Aug 2004 00:20:09 -0700 (PDT)
To: Alberto Reggiori <alberto@asemantics.com>
cc: public-rdf-dawg@w3.org
Message-ID: <20040826001038.R83257@skutsje.san.webweaving.org>

Just some (personal) background to Alberto his use case.

Within various fields we are seeing several ways of using RDF:

->	A single 'file' with facts authored by a single entity.


->	A single file with facts taken from different authorties,
	or invented locally.

->	A URL pointing to that 'file'.

->	Depending on the operational requirement; the system
	using the data may either fetch the file and internalize
	it OR just keep refering to that URL.

Now the transience down the line is the problem; some facts are really
authored by the relevant authority - and should be considered simply as a
local copy - whereas other triples are created by more than just some
smushing; and are originating at some point in the federated processing
path. Alberto's example for foaf files form different people beeing merged
and augmented with, say, information from IMDB, is a good example.

But regardless at some point is it needed to be able to modify, delete or
identify the facts from a given 'authority' (in the loosest 'source' sense
int he world) on a per 'entity' basis. Even though you've dumped them into
one database all together.

Pragmatic solutions sofar have been keeping provenance and context at all
time when we're working with a copy of the facts -or- using just a URN (or
some other URI such as a URL) rather than a copy of the data and rely on
fast fetching/caching from the 'origin' when it is really needed.

Received on Thursday, 26 August 2004 07:31:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:44 UTC