- From: pat hayes <phayes@ai.uwf.edu>
- Date: Sat, 23 Jun 2001 23:22:15 -0500
- To: Sergey Melnik <melnik@db.stanford.edu>
- Cc: w3c-rdfcore-wg@w3.org
>Brian McBride wrote: > > > > Hi Sergey, > > > > Sergey Melnik wrote: > > > > > > Brian, > > > > > > I'd just like to reiterate some of the arguments for making reification > > > a built-in feature (possibly as an optional layer): > > > > I wasn't sure what you meant by 'built in' but I guess you mean >specifically > > called out in the abstract syntax. > > > > > > > > - in M&S, reified statements need to have a URI. It looks like they > > > should be unique, but nobody wants to deal with uniqueness, but still > > > some sort of URIs need to be assigned, so we end up having to deal with > > > different URIs denoting the same statement etc. > > > > I have the same question as Danbri here - why do they have to have a URI. > > M&S allows there construction without. > >I'm tempted to postpone arguing about this issue until we worked out >what anonymous resources are and whether we need them. However, I'd like >to point out that if you want to use reification in databases, you may >avoid unintuitive query results if reified statements are unique, i.e. >have same IDs, whatever they are. To be frank, I only see unnecessary >complications associated with "multiple occurrences" of reified >statements, or anonymous resources, but no tangible benefits. ?? Sergey, you seem to relating anonymous nodes with reification in some way. To me they seem two distinct and unrelated topics. Can you expand on the connection you see between them? > > > - in M&S, we need a specific vocabulary to express/use reification. > > > Reification could be defined without relying on vocabularies. > > > > I'm wondering what you mean here by 'relying' on vocabularies. Reification > > is currently defined using rdf:type, rdf:subject etc. Those are > > vocabularies. > >I'm joining Graham's suggestion on this issue. > > > > - as defined in M&S, reification is extremely verbose and clumsy both in > > > APIs and in the syntax, and very few people are using it as suggested. > > > However, I personally believe it is a useful feature when introduced > > > correctly and compactly, and it can be easily handled in APIs and > > > databases as an intrinsic model feature. > > > > Absolutely. > > > > > > Finally, (s1 p1 (s2 p2 o2)) looks nicer in the abstract syntax... > > > > Right. Much neater and simpler. However ... > > > > There has been a bunch of discussion lately on www-rdf-logic about this. > > It would be very helpful if one someone who understands these issues > > (far) better than I (Pat, FrankM, ? please) could summarize the >key points - > > and > > straighten me out if what I'm about to say is wrong. > >I'd love to see this summary, too... > > > The upshot of that discussion is that there are (at least) two different > > concepts floating about, distinguished by the ideas of 'use' and 'mention'. > > > > The simplest examples to distinguish these I have seen are: > > > > London is a city. > > 'London' is a word. > > > > The first of these is use, the second is mention of the name 'London'. > >I have a feeling that this example might be too simple to illustrate the >problem, since it could be tackled using urn:cities:London and >urn:rdf:literal:London. The point is not that the distinction can't be represented, but that it is a real distinction that needs to be respected. > > > A logical language needs both mechanisms. Reification, as described in > > M&S is an example of mention e.g. Ralph said 'the sky is blue'. > > > > My working assumption at the moment is that reification is a different > > mechanism from nested expressions. If we use nested expression syntax > > to represent reification, then a future working group can't use it > > to represent nested statements. > >I tend to agree. My impression is that reification provides a >qualitatively different instrument, which allows referring to states of >affairs, ?? Surely referring to states of affairs is what the basic logic does. Reification refers to sentences, sentences describe states of affairs. > so the distinguished notation would be justified. I think if we >need nested expressions (e.g. for representing LISP, rules etc.), we can >always define some dedicated vocabulary. Ideally, the semantics of such >a nested expression would be consistent with that defined by RDF "core" >(i.e. a nested expression in the abstract syntax would be interpreted as >a nested expression in the domain of discourse), I dont follow you here. Right now there isnt any nesting in the RDF core. >with additional >interpretation functions or relations that would help to capture the >extra semantics. Again, I'd appreciate a logician's summary on those >issues... It would be desirable to have any nested syntax have current RDF as a special case, certainly, but seems to be rather awkward to do with RDF in its present state. Here's the problem. To represent any kind of nesting within the RDF triples framework seems to require treating the nested subexpressions as some kind of container. Doing that, however, means that the 'nested-syntax' assertion that had the same meaning as a simple RDF triple would not be a single RDF triple, but something like a triple whose subject and object were containers with single elements. One could make artificial definitions to arrange that a one-element 'nest container' was equivalent to its only member, of course, so it would be *possible* to do it; but not to do it naturally. (My proposal to use argument lists rendered using triples encoded with 'etc' was an attempt to do this so that the binary-relation case turned out to be ordinary RDF triples, but that coding technique was broken, as Sandro explained. In effect, it needs quads rather than triples. If the basic RDF item were a quad rather than a triple, it would be easy to extend RDF naturally to any arbitrarily complicated syntax.) Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes
Received on Monday, 25 June 2001 10:43:38 UTC