W3C home > Mailing lists > Public > www-rdf-logic@w3.org > May 2001

RE: use/mention and reification: rdf:predicate/subject/object [was: RDF Abstract Syntax...]

From: Graham Klyne <GK@NineByNine.org>
Date: Sun, 27 May 2001 15:59:15 +0100
Message-Id: <5.0.2.1.2.20010527152731.03632480@joy.songbird.com>
To: "Jonathan Borden" <jborden@mediaone.net>
Cc: "Dan Connolly" <connolly@w3.org>, "Drew McDermott" <drew.mcdermott@yale.edu>, <www-rdf-logic@w3.org>
At 09:16 AM 5/27/01 -0400, Jonathan Borden wrote:
>Yes exactly. I was specifically considering this point. Note that in the
>proposed abstract syntax, assertion and reification are distinct. One can
>refer to a statement that either is or is not asserted within a particular
>context.

I think it is useful to recognize the distinction, though I'm still 
inclined to believe it can be adequately captured in triples, given an 
appropriate approach to the semantics of reification.

>Another point: CWM does not use triples rather quads. (p,s,o,context) so it
>appears this intellectual barrier of the arc being a triple has already been
>broken ... indeed numerous implementations/APIs do not deal with base
>triples. [...]

I accept your arguments for the efficiency of representations based on a 
richer structure than triples, but I'd also point out that these efficiency 
considerations are largely implementation concerns.  I myself have 
previously discussed non-triple based representations, but I have also 
been  clear that these can be grounded (are mappable to/from) a 
triple-based form.  I think it's pretty much inevitable that 
implementations will chose to use different internal representations:  IMO 
the triples (assuming they can support adequate semantics) may form the 
underpinning for all these representations.

I think their is a fair community investment in the triple form, and that 
it should not be discarded unless we are certain that it is fundamentally 
inadequate.

[...]
>If we can agree on
>a internal structure by which to represent individual and compound
>statements (i.e. expressions), then we can describe a logic language in
>these terms.

Well, yes (but I'd delete the word 'internal' from your statement)... and I 
think alternative proposals (such as yours) help to clarify the issues.  If 
we are to settle on a common structure I think we should be looking for the 
simplest possible such structure, per "principle of least power".

...

And some personal thoughts about your proposed representation:

I cannot help wondering if it has gone too far in the opposite 
direction.  In my musings about statements and contexts [1], I settled on a 
quadruple-based structure (different from the CWM structure you describe), 
which (in some interpretations) would treat <id,p,s,o> as a reification of 
a statement '(s p o)' with identifier 'id'.  I find that, with additional 
RDF properties (and associated semantics), this seems to be capable of 
capturing the important aspects of the expression you mention, thus:

You propose a Statement is represented by the 7-tuple:
   <predicate,subject,object, contextURI,id, index, asserted>

Your 'ContextURI'+'id' serve the same purpose as my id.  reserving the 
components of a QName structure has some appeal, but I'm not clear if it 
needs to be done at this level.

Your 'index' is to do with preserving information about lexical ordering of 
statements.  I have serious doubts that this has a place in the RDF 
r5epresentation:  either the ordering is significant in which case it 
should be captured in the RDF graph, or it is not.  (I note the arguments 
that order is "semi-significant", but do not think that these justify 
complicating the core RDF structure.  Individual applications are free to 
preserve additional information as they see fit.)

Your 'asserted' property is captured in my framework by an explicit 
property linking the context in which the statement is asserted to the 
reified statement.  Thus, an asserted statement needs two tuples:  one to 
describe the statement, and one do describe its assertion.  I am 
comfortable with the additional tuple required;  for some purposes (e.g. 
mine!) I feel it is more expressive.

#g
--

[1] http://public.research.mimesweeper.com/RDF/RDFContexts.html



------------
Graham Klyne
(GK@ACM.ORG)
Received on Sunday, 27 May 2001 11:13:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:35 UTC