"Being abstract is something profoundly different from being vague … The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise." EwDijkstraQuotes
----
I was in Munich a few years ago, speaking at something (OOP or something, I can't really remember). BruceAnderson was there, and we sat together listening to David Taylor go on about something. I wasn't getting it, but Bruce did. He said that David was being vague (it was a fairly superficial coverage of the material David was working on). I asked if he was being abstract, and Bruce then explained the difference (I'm paraphrasing; Bruce can correct this if I've blown it):

	 :	''The difference between vague and abstract is that when you're being abstract you can drill down to a level of detail appropriate to answer a question. When you're vague, you can only wave your hands and deflect the question.''

-- RonCrocker
-----
I worked with David Taylor for a few months. He's a very visual thinker, and communicates best at a large whiteboard. Not to say that he can't be vague at times, but I can imagine him sitting on a panel squirming with the desire to grab a marker and start drawing. --DaveSmith

-----
I'm not commenting on Taylor's talk, rather the distinction between two general forms of high-level discussion. --RonCrocker
----
How does one tell the difference? If one can turn an idea into a mathematical notation, then it's not "vague" within that notation. But sometimes applying such to something more explicit, such as a software implementation, requires making assumptions or interpretations. If my math model says all foos added to gogs are nibbles, then we have a clear rule in that notation. But determining what is the foo and a gog in an explicit implementation may be subject to non-unique interpretation. Being clear in a WalledGarden notation system (math) is easy; applying it to the real world and still being clear or non-arbitrary can be tricky. -t

''Mathematical notations are orthogonal to abstraction.  Abstraction is about dealing with relevant generalities instead of irrelevant specifics.  For example, if we're talking about "road vehicles" as an abstraction for modelling traffic flow, it doesn't matter what colour the cars are or what sort of doohickey they've got hanging from the rear view mirror.''

{"How does one tell the difference?" Something is abstract if some irrelevant details are ignored. Something is vague if there are things to which it both applies and doesn't apply. The two concepts are logically independent so we can have things that are one, the other, both, or neither. Everything after your question appears to be comparing abstract to concrete, so I'm not sure what it has to do with your question.}

* Relevancy is relative. Do you have a simple example of both being independent?

For example, "true" relational requires that each "row" (tuple) be unique. Technically every row has a unique address inside the machine because that's the way our current hardware works, and sometimes this unique address (or equivalent) is available to RDBMS users. But does that really qualify each row as "unique"? In a "domain sense" a row could be considered non-unique since the unique address is not a "domain field", but a '''side benefit from the internal guts'''. But what we consider to "count" as a unique key/identifier and "don't count" is subject to interpretation. A technically unique key and a practical unique key may be different things. (For one, low-level keys/addresses may change over time.) It's more of a political/sociological/utility (WetWare) issue than an issue with theory itself. Relational theory doesn't discount frequently-changing keys; the "rows" just need to be unique at any given slice of time. -t
  First-Name Last-Name Internal-ID
  -----------------------------------
  Bob........Jones.....3cfe84a7c // note how we have 2 Bob Jones'
  Bob........Jones.....7a389cb8f
  Martha.....Stewart...e68b89bfc
''If that Internal-ID isn't visible to the user, then the two rows are not unique.''

"The user" is relative. It could be a DBA, app developer, power user writing SQL, or an end-user, for example. We can talk about viewpoints (access rights etc.), but that's still relative.

''The only relevant viewpoint here is whether Internal-ID is visible to the user or not.  As soon as Internal-ID isn't visible, if duplicates are visible, the user isn't dealing with the RelationalModel.''

So "relational" is a viewpoint then, not a system architecture?

''The RelationalModel is a DataModel consisting of relations and the RelationalAlgebra.  If a system delivers a tabular structure to you with duplicate rows, it is by definition not a relation, and therefore at least that part of it is outside the RelationalModel.''

Then claiming that existing RDBMS are not "true relational" is misleading because discarding the key from "output" is a user choice just as it is in RelProject. I will agree that the degree that a given DB system "makes it easy" to discard a key from output varies widely, but that's not a Boolean classification between "relational" versus "non-relational". Saying that System A "facilitates" relational (uniqueness) more so than System B is certainly acceptable, but "more so" is not Boolean. And if you import a bag, all RDBMS give the rows an internal key at some level such that technically each row is unique (although "is" is perhaps Relative to viewpoint). It may not map to something unique in the domain world, but (formal) auto-keys have that "problem" anyhow. RelProject allows auto-keys, no? Either we pick a specific reference point (viewpoint) or "pretend" something is a bag by not considering internal keys/addresses '''in our head''' as a hopefully UsefulLie. In short, TrueBagsCannotExist.

----
CategoryComparisons, CategoryTheory