- From: Bob MacGregor <macgregor@ISI.EDU>
- Date: Wed, 08 Jan 2003 14:37:33 -0800
- To: jena-dev@yahoogroups.com
- Cc: Dave Reynolds <der@hplb.hpl.hp.com>, www-rdf-interest@w3.org, jena-dev <jena-dev@yahoogroups.com>
- Message-Id: <5.1.1.6.0.20030108140508.00b2d380@tnt.isi.edu>
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
Attachments
- image/jpeg attachment: 13ea102.jpg
- image/jpeg attachment: 13ea1ca.jpg
Received on Wednesday, 8 January 2003 17:50:47 UTC