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

Re: Statements/Reified statements

From: Bill de hÓra <dehora@acm.org>
Date: Wed, 22 Nov 2000 22:17:13 -0000
Message-ID: <003a01c054d2$0e120060$9b8d883e@dehora>
To: "Sergey Melnik" <melnik@db.stanford.edu>, "Pierre-Antoine CHAMPIN" <champin@bat710.univ-lyon1.fr>
Cc: "ML RDF-interest" <www-rdf-interest@w3c.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- ----- Original Message -----
From: "Sergey Melnik" <melnik@db.stanford.edu>
To: "Pierre-Antoine CHAMPIN" <champin@bat710.univ-lyon1.fr>
Cc: "ML RDF-interest" <www-rdf-interest@w3c.org>
Sent: 22 November 2000 21:52
Subject: Re: Statements/Reified statements


: Pierre-Antoine CHAMPIN wrote:
: > ...
: > First, Statements and Reified statements are not the same thing.
:
: Although this is consistent with the spec, I believe there are
: significant advantages both for understanding and manipulating
reified
: statements if these two notions are merged into one.
:
: Can you (or anyone) list some use cases where it is beneficial to
make
: this distinction? I can think of several cases, in which
distinguishing
: statements vs. reified statements makes things a lot more
complicated.
: Just consider a database query that retrieves all assertions made
about
: a statement (by anyone).
:
: The M&S spec clearly states that statements are *non-atomic*
entities in
: the RDF model, i.e. they have 3 identifiable parts. Why then
getting
: into trouble of defining another mechanism ("quad reification") for
: identifying these same parts in a less efficient (in all senses)
manner?

I agree with this: quad refication in my mind neccessarily implies
some kind of syncing and transaction mechanism across the quad: you
can do it but it's a pain. With due respect to Pierre, I'm not keen
on partial information over reified statements, however non-spec
breaking that may be. It's a natural types question that we can go
round and round on.


: Consider a mathematical model for RDF: given an entity S we will
always
: be able to tell whether S is a statement or not (by testing whether
S is
: a member of set "Statements"). Given that S is a statement we will
: always be able to gets its subject, predicate and object (e.g. we
refer
: to such X that there exist Y and Z with S=(X, Y, Z)). Thus we can
pretty
: safely assume that any RDF API or storage facility will provide
similar
: capabilities.

Ok, and wrt below: we can bind differing 'representations of a
statement' to statement using (s,p,o) irregardless of the resource
that reifies. What about where 'o' is a possibly system generated
resource that reifies a statement: can we just ask of its (s,p,o) in
turn until we bottom out to an o that is not denoting another
statement?


: The "fix" or interpretation I advocate is the following:
:
: - STATEMENTS ARE RESOURCES (that implies that every statement is
unique
: and equivalent to reified statement)
: - toss "quad" reification mechanism altogether
:
: If someone chooses to reply to this posting, please be
constructive. If
: you claim reification should be done in this or other way, justify
you
: opinion, or tell what the drawbacks of the above suggestion are.
There
: are many ways to express the same thing which are all theoretically
: equivalent. However, we have to store reified statements, send them
over
: networks and use in query processing. Keep that in mind.

Just to clarify: I understand you to say that "statement isa
resource", not "statement hasa resource". Is that correct? So in java
for example I could practically reify a statement object by
downcasting it to a resource for insertion into another statement
(isa), or, I could just ask for its reified form (hasa).

One other thing (I essentially agree with this btw). How would one
add a reified statement to a container (such as a jena/stanford
Model) without asserting it? Carry tables for assertions and
refications and indicate that a statement is present in reified form
but "not asserted here" (nah)? It's certainly simpler than
maintaining quads.

+1

- -Bill de hÓra

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0

iQA/AwUBOhxF2uaWiFwg2CH4EQJfIgCdGuxVOKemCbFsArPaAvMKu2mPNzgAmwU0
5LOu+zSJtpq7I+FLrIQa8GG8
=tInh
-----END PGP SIGNATURE-----
Received on Wednesday, 22 November 2000 17:19:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:46 GMT