- From: Frank Manola <fmanola@acm.org>
- Date: Sat, 28 Aug 2004 11:59:49 -0400
- To: Bob MacGregor <macgregor@isi.edu>
- CC: www-rdf-interest@w3.org
Hi Bob-- Some comments below. Bob MacGregor wrote: > > Hi Frank, > > You make many good points; I don't like to get deeply nested, so I'll > respond just on top. > > You say RDF already has containers. True -- its easy to create a container > of things that denote "entities", but its MUCH less practical to create > a container > of statements. Yes, its doable, but this is the Turing argument all > over again -- we > already have assembly language, but we would like to code in Java. I understand what you say about the ease of creating containers of statements, but I don't think this is quite the Turing argument. In the first place, you're proposing to add *another* container construct. There certainly may be good reasons why another such construct is needed, but it seems reasonable to me to look at this pretty carefully (e.g., look at how it interacts with the existing containers which, as I pointed out, can still be used for this purpose). After all, I don't think we want to duplicate the situation we were in with the current reification vocabulary. In the second place, it seems to me that the difficulty you describe in creating containers of statements is largely due to the difficulty of identifying statements, rather than the need for a new container per se. Granted that a special kind of container just for statements might (indirectly) help deal with some of those problems, but if, for example, I ultimately need to identify individual statements, creating a separate container for each statement seems like unnecessary indirection. > > You are insisting on semantics. RDF has almost no semantics -- graphs are > just graphs; there is no attempt to assign truth per se. I'm pushing > for named > containers, another data structure, with no built-in semantics pe se > (except > that the contexts I use allow for contexts within contexts, which induces > a few entailments). Note: Pat Hayes has carefully insured that RDF > statement > reification has essentially no semantics. I understand what you're after. My point is simply that if you have a purely structural approach using containers and nothing else, one person might use the container for indicating provenance, and other might use the container for an entirely different purpose, and there would be no explicit indication which was which (worse, different people might use the same structure in *slightly different ways* to indicate provenance). My main concern isn't just to represent stuff, but to do so in a more interoperable way. Hence my belief that we need somewhat more than simply a new container structure (even if it's only some additional conventions). Note: You needn't saddle Pat with all the "blame" (if that's what it is) for the state of reification. In the first place, the entire RDF Core WG is responsible for the specs as they stand, not just the individual document editors. In the second place, the WG found the reification vocabulary in a confusing state, and picked what seemed to be the most reasonable interpretation for the provenance use case. The fact that reification has almost no semantics mostly follows from the ability (or lack of same) of RDF to reflect those semantics (the point you made at the beginning). > > Basically, you are advocating a cerebral exercise, followed by adoption. > The problem is that its hard to appreciate the utility of something like > contexts unless you have the option to use them (not just imagine what > it would be like). Reified statements are a good negative example -- on > paper, they look promising, but in practice they s*ck. Only relatively > few of us have the luxury of building applications using a real context > mechanism > (have you?). > If by "advocating a cerebral exercise" you mean advocating thinking a little more about fundamental additions to RDF (and their interactions with the existing facilities), then that's certainly what I'm doing. In particular, I fully appreciate the utility of "contexts" for doing dozens of useful things, just as many other people have since McCarthy's notes, and Guha's dissertation. The problem is that those dozens of useful things tend to involve different meanings and, as I said above, I'm concerned about interoperability. Cheers, Frank
Received on Saturday, 28 August 2004 15:57:15 UTC