W3C home > Mailing lists > Public > www-rdf-interest@w3.org > December 2002

Re: cwm/n3 and naming blank nodes?

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Sun, 01 Dec 2002 16:09:07 -0500
To: www-rdf-interest@w3.org
Message-ID: <87smxha1l8.fsf@nwalsh.com>

Hash: SHA1

/ "Seaborne, Andy" <Andy_Seaborne@hplb.hpl.hp.com> was heard to say:
| Given RDF's open world assumption, the absence of the "p:died" does not mean
| that no such statement has been made somewhere or will be made.  You might
| merge in some more RDF which did contain the statement "ab:jdoe p:died
| "1999-12-31".

Hmm. Yes, I can see how that's generally true.

| There may well be other, better solutions, but one approach would be to give
| end dates to all people - and make it a bNode where it is as yet unknown
| ((are literals resources at the moment?)).  Appointments also always have
| end dates, although it might be unknown.  Your application can choose to
| interpret "[] db:end []" as unknown and mean repeat forever (i.e. repeat
| until known to have passed). 
| There is now only one rule that triggers on each contact record so I think
| you only get one appointment per contact.

That works, but that's not a terribly satisfying solution. For one
thing, it means I have to add a whole bunch of 'p:died []' statements
to all the entries.

Given that I'm going to run this through cwm, I'm sort of hoping
there's some closed world solution :-)

I'd be quite happy with giving these things names. Any joy there? Can
I manufacture a new name based on an old one in a rule?

                                        Be seeing you,

- -- 
Norman.Walsh@Sun.COM    | To enjoy yourself and make others enjoy
XML Standards Architect | themselves, without harming yourself or any
Web Tech. and Standards | other; that, to my mind, is the whole of
Sun Microsystems, Inc.  | ethics.--Chamfort
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

Received on Sunday, 1 December 2002 16:10:20 UTC

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