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

Re: [jena-dev] Re: Use cases for Reification in RDF Triple stores

From: Bob MacGregor <macgregor@ISI.EDU>
Date: Wed, 08 Jan 2003 14:37:33 -0800
Message-Id: <5.1.1.6.0.20030108140508.00b2d380@tnt.isi.edu>
To: jena-dev@yahoogroups.com
Cc: Dave Reynolds <der@hplb.hpl.hp.com>, www-rdf-interest@w3.org, jena-dev <jena-dev@yahoogroups.com>
A very nice summary of the statements v. stating issue is in

     http://ilrt.org/discovery/2000/11/statements

Near the end, three positions are layed out:
   (1) 'reified statements are statings'
   (2) 'statements are resources'
   (3) 'change the model' (not a very self-explanatory label)

I personally don't endorse the first interpretation, but I assume that
Seth does (see below).  Thus, for him, quads make sense.  I prefer that there
be a one-to-one correspondence between statements and
their reified counterparts.  For me quads don't make sense.  I doubt
if any amount of discussion will resolve this difference.

It appears to me that the second and third positions are not that
different, and could be harmonized.  In any event, I more-or-less
agree with both of them.

Jena's "shortcut" reification would seem to implicitly require a
one-to-one correspondence between statements and their
shortcut reifications (the mapping being the identity function).
And, a shortcut reification can appear wherever a resource
can appear (i.e., the shortcut is a resource), and the shortcut
used as an argument functions just like a blank node (as in the
example for Position 3).  Perhaps Jena's shortcut reification
represents a clever way of endorsing positions 2 and/or 3?

In any event, the semantics that you get using the shortcuts
is what we want, and if/when we start using fully reified
statements, we expect to introduce constraints/side-effects
that will ensure that semantics.  For example, we may require
that a statement must exist corresponding to every reified
statement (but not the reverse).  And we will require that
two different reified statements cannot have the same s/p/o
values (whereas quads explicitly permit this).

A part of my original use case question then becomes, how
efficiently can we implement these constraints using a triple
store API?  For example, if  a retrieval returns a statement
<a,b,c>, does it take a second query to determine if there
exists an X representing its reification (i.e., such that the triples
<X, subject, a> <X, predicate, b> <X, object, c> exist)?
It would be nice if the API gave us a fast way to acquire
X (if it exists), given a statement <a, b, c>.   In an earlier
e-mail, I was wishing for a resource associable with
a shortcut reification.  The X above can be that resource.

Cheers, Bob

At 01:46 PM 1/7/2003 -0800, Seth Russell wrote:
>Bob MacGregor wrote:
>
> > What Jena calls a "shortcut" we consider to be the right way to reify
> > (except that
> > technically, its not reification at all, its just allowing statements
> > to be arguments).
> > Logic-based KR systems (MRS, Epikit, Epilog, Cyc, PowerLoom, SNePS,
> > etc) have
> > been using the "shortcut" style of reification for a very long time.
> > Its not a curiosity;
> > its part of the fabric. For example, to represent a disjunction of two
> > triples, you create
> > a triple that nests two (or more) other triples:
> > <<a,b,c>, OR, <d,e,f>>
> > Note that with this kind of usage, its critical that the nested
> > triples not be considered
> > as asserted in the model.
>
>Yes this is substantually the way I do it with Quads.  I've capatilized
>"Quads" because it does not refer to the four triples used by RDF, but
>rather to arrows that have 4 attributes.  The  four attributes are
>(graph, subject, property, object).  Below is a mentographs that show
>this usage.  We put arrows in Venn diagram  like circles to show in
>which graph (model) they reside. The arrow heads on the circles are an
>artifact of the tool I use and do not signify an arrows.
>
><http://robustai.net/mentography/or_not.gif>http://robustai.net/mentography/or_not.gif
>
>Every arrow in that diagram is a Quad.  There are graphs  (or Jena
>models if you like) involved in representing the text: "Some image
>depicts Sally or John".  One graph (_:a) in which some:image depicts
>Sally and one graph (_:b) in which some:image depicts  John, and one
>graph (_:d) that contains the rule that "nests" _:a and _:b such that
>one or the other graph is true.   That sounds like a lot , but there are
>really only 4 records in the data base.  I've written them in Quads
>formt (subject, property, object, graph) below:
>
>some:image depicts Sally _:a
>some:image depicts John _:b
>_:c or _:a  _:d
>_:c or _:b  _:d
>
>The reason that I am touting Quads, is that they translate directly into
>RDF triples and can represent just about anything *just as long as* we
>have some way to identify graphs (Jena type Models) as first class
>resources.   Not allowing ourselves that privledge is to hopelessly
>complicate our RDF based APIs  just when things become interesting.
>
> > One final comment on quads vs. the  'getIt'/'setIt' that I am
> > advocating.  They
> > are not equivalent.  With quads, we can assert a triple twice, with
> > two different
> > fourth arguments:
> >     <a, b, c, d1>
> >     <a, b, c, d2>
> > Here, there is no explicit means for detecting that 'd1' and 'd2' are
> > annotating
> > the same 'triple', since the notion of triple has now evaporated.
>
>Huh?  I don't know about Jena, but detecting that the graphs named 'd1'
>and 'd2' above contain the same triple <a,b,c> is childs's play .. what
>are you talking about?
>
> > I'm advocating
> > that we keep 'triples' as the are, while adding a means for
> > efficiently attaching
> > meta-information to a triple (short-cut reification provides a less
> > efficient means
> > for attaching meta-information to a triple -- that is what we will use
> > for now, but
> > we take a performance hit doing so (as exemplified by the 'deleteResource'
> > example in my previous message)).
>
>The most efficient way is just to use Quads ... no performance hit
>whatsoever.  But I am talking in general, I dont know anything about the
>Jena in particular.
>
>Seth Russell
><http://radio.weblogs.com/0113759/>http://radio.weblogs.com/0113759/
>
>
>
>Yahoo! Groups Sponsor
>ADVERTISEMENT
><http://rd.yahoo.com/M=241773.2725424.4169802.1925585/D=egroupweb/S=1705007181:HM/A=1394046/R=0/*http://www.hgtv.com/hgtv/pac_ctnt/text/0,,HGTV_3936_5802,FF.html>13ea102.jpg 
>
>13ea1ca.jpg
>
>To unsubscribe from this group, send an email to:
>jena-dev-unsubscribe@yahoogroups.com
>
>
>
>Your use of Yahoo! Groups is subject to the 
><http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.

Robert MacGregor
Project Leader
USC Information Sciences Institute
4676 Admiralty Way, Marina del Rey, CA 90292
macgregor@isi.edu
Phone: 310/448-8423, Fax: 310/822-6592
Mobile: 310/251-8488



13ea102.jpg
(image/jpeg attachment: 13ea102.jpg)

13ea1ca.jpg
(image/jpeg attachment: 13ea1ca.jpg)

Received on Wednesday, 8 January 2003 17:50:47 GMT

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