More use cases for nondescript resources

nondescript is a funny word. Quite sure I did not catch its correct meaning when I first heard it. It has no real equivalent in French. Indescriptible is too strong, it refers to something too extraordinary to be described, whereas nondescript is actually too ordinary to deserve a proper description. Or is it that any description would miss the point? The free online dictionary says : Lacking distinctive qualities; having no individual character or form. Maybe in fact nondescripts remain such because those features which makes their individuality are too subtle to be captured, or this capture would be useless.
Anyway, let's take them as they are : no description. What does a nondescript look like in RDF? Well, easy, it's a resource with no description. No type, no identity, no properties, certainly not even worth a URI. A blank node with no property whatsoever. Rings a bell now? After the previous post, I've come out with more use cases for those nondescript resources, and how natural language uses them as binding points. Examples

John walks through the neighborhood where Ann is working.

:John :walksThrough _:n
:Ann :worksIn _:n

In The Rule of Four (currently reading) Vincent and Richard have different theses about Hypnerotomachia Poliphili. Paul prefers Richard's thesis.

:Vincent :hasThesis _:tV
:Richard :hasThesis _:tR
:Paul :prefers _:tR

Now the "Class or Concept" example comes naturally as just another case

a:Restaurant a owl:Class
b:Restaurant a skos:Concept

a:Restaurant :represents _:x
b:Restaurant :represents _:x

Cloud hidden, whereabouts unknown. (Similar stuff in the early '70s)


Identifying things - blank nodes again

Still trying to figure if the hubject seeds are likely to grow somewhere, so I dropped one today on Danny Ayers' blog, as a comment on a post itself commenting on another one from Jon Udell where is introduced the cool notion of collaborative aliasing. "What a concept!" will say Jack. And actually, it's no more no less the idea that hubjects can be created out of aggregation of resources being "about the same thing". An aliasing service, which really looks like tagging.
So my suggestion again is here to use blank tagging, that is, allow users, in a simple way, to make all those resources point to the same blank node.
Now something is slowly coming from the back of my mind. I thought for a while we needed a specific and mysterious vocabulary to do that, hubjects and the like. Since this kind of stuff is far from being on the track of adoption, maybe using more popular and less exotic vocabulary, such as dc:subject or something similar would make the whole thing more understandable. Seems there is no formal opposition to declare things like:

http://www.amazon.com/gp/product/B00006RCLH dc:subject _:b
http://labs.oclc.org/xisbn/068981836X dc:subject _:b
http://en.wikipedia.org/wiki/Call_of_the_Wild dc:subject _:b

And actually, any other property could be used as well, such as the following, to take the example from Jon Udell's post
http://upcoming.org/venue/3669/ a:venue _:x
http://eventful.com/venues/V0-001-000150985-3 a:venue _:x

This kind of declaration keeps completely agnostic on what a venue in general, and this particular one actually is. It simply says that the two resources are about the same one.