- From: Bill de hÓra <dehora@acm.org>
- Date: Wed, 22 Nov 2000 22:17:13 -0000
- 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 UTC