terminology for scope of discourse, i.e. CS-domain

I noticed a lack of good terminology to discuss mixed content intended for different uses -- or merely for alternate focus -- depending on 1) what sort of tool might work with it, or 2) what kind of activity or analysis is in scope. The idea I want means something like "asset class" but is also covered by "domain" in its general sense, except many people accept only one sense of a word upon first hearing. (Insert a comedy dialog here: a physicist mentions a magnetic domain in an iron object, only to be blind-sided by a troll who explains internet domains do not apply in that context.)

Typically people put different asset classes in different files, and say "this file's content is for that tool", but never talk about what they have in common besides that they are "files". Some tools might want to perform cross-domain analysis, or code generation. But it's hard to describe without enumerating "now we do X" and "now we do Y"; and the relation of X and Y is idiosyncratic and specific, rather than being generally alternate asset class domains.

The term "aspect" in aspect-oriented-computing is related, except no one will know what you mean if you use aspect as a synonym for domain. If you take content from different asset class domains, and mix them together in one file (with related things near each other for easier reference), with each one scoped suitably via syntax of some kind, there isn't a good word that denotes what is inside each scope. In one you have "stuff about X", and in another you have "stuff about Y", but stuff is pretty vague. You can put them in different logical files in an archive, but a problem of crummy terminology remains.

For example, suppose in one scope you have a bunch of code that "does task X", and in another scope you put a description of sequence diagrams that ought to result from that, so a tool can generate test code or perform analysis for verification. (A typical reason to do this might be that one asset is an emergent result of another asset class, and very hard to see unless explicitly described.) In a more general case, you might want to characterize what several sorts of program are doing in a larger system.

What I'm looking for is terminology about the semantics of expressing different things, perhaps in different languages, and making statements or queries about their relationships in space, time, or causal interactions. (The obvious response is "don't do that"; in a comedy dialog, one party can ask "why do you want to do that?" while pushing either focus on X or focus on Y, with no concern about how they relate -- it's someone else's problem.) Probably each domain has its own type system, but that doesn't seem very helpful here.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

hm

You mean "domain" as in "domain-specific language"?

domain-specific

You mean "domain" as in "domain-specific language"?

Yes, sort of. :-) Term domain in DSL is a bit hand-wavy, typically meaning narrow as opposed to general (in a language), where the wikipedia page on Domain-specific_language defines domain implicitly, by example, in terms of an application that processes it -- like html web pages, or scripts for Perl, Awk, or shells. Why those are domains is left implicit in the prose there.

I mean something more general by domain, in the sense it need not be for a historically well-defined app. It can instead be "area of discourse" in whatever way makes sense semantically in what you are doing. Some domains (e.g. here is a block of text intended to be prose) might be content that works equally well in several more narrow domains that also include understanding them (like blocks of prose text). So domains may vary in specificity about what you are trying to do. Some scopes may be more context-free, working in multiple domains, if you viewed them from the POV of those domains.

Lack of clarity in my paragraphs above is one reason "domain" is not a very good synonym for "asset class" in my original post.

Resources or Materials

I tend to use "resources", and of course resources can have a "type", in this case I mean a formal type rather than a "file type". For example you might simply view a JPEG file as an array of bytes, but you could also go into more detail with the actual data-structures, once you have defined the 'file address space' as a kind of pointer. I have also come across "materials" for this use.

synonyms for bulk goods

Thanks, I was hoping for something that jarred my perspective. I like both resource and material. Mulling these over, I decided I didn't want a term, I want a metaphor that terms should follow. And here the metaphor I like is that digital materials are just like real world non-digital materials, so use the same word you would in a similar situation. If you take inventory of what is on hand, you call each thing by whatever word covers the role that matters to you: resources, assets, junk, bulk content, items with serial numbers, whatever. Material executing at runtime tends to favor words that imply behavior.

Each fragment of material is an instance of some general class in a usage domain. So domain is something general about a class of items. You can call items of digital content whatever you want, depending on a role emphasized. Term "fragment" emphasizes role as piece of some larger whole. Using fewer terms actually doesn't help, since information theory says you convey less by a word the more likely that word is to appear. A term repeated over and over thus becomes bleating, so varying synonyms can improve clarity.

This view makes my original point pretty uninteresting, which seems good. Little is left besides domain change across fragment boundaries.

Metaphors

I like your point about metaphors. It reminds me we have "desktops", and "windows" etc. I guess the human brain is hardwired by evolution to prefer certain physical representations. We will always find it easier to catch a ball, than we do to calculate it's trajectory by calculus, even though we are solving the same problem in both cases. Finding the right metaphor can make complex problems simple. There is already a link between software and construction as we already use the metaphor of architecture.

If only I had mentioned reductionism in this post

My point was partly that metaphors are not false. Some folks may assume, "You can't use metaphors because that's not what is actually happening." But I suggest if you are understood, then part of truth relevant at the moment is getting through. When you design something based on a metaphor, and code obeys that model, then metaphor is what actually happens at some level of abstraction.

Historically, "metaphors are great" is strongly associated with user interface design. Users are shown windows and desktops, but they are simulations and not "what actually happens". However, if code has frameworks and objects involving windows and desktops, maybe it really is partly what actually happens. I suppose there's no reason to limit metaphors to just GUI entities. And in practice we don't because we have all kinds of abstract models in software systems, like heaps and stacks and processes. These are real when the model applies, as opposed to convenient figments.

I was suggesting there is no level of abstraction where metaphor is inappropriate. When you speak figuratively, but it captures a model correctly enough, then it is true to the extent anything we say in natural language approaches true. Even when determined to hew to a hardware perspective, hardware must be designed to follow models that makes sense to us, so metaphors are present. Sometimes the metaphor is a story with numerous actors. (This is practically what instruction architecture means.)

Calculus of moving objects is sometimes less impressive than it seems when "constant rate of closure" is a good enough approximation. To stay on a collision course, you need only maintain the same bearing with a target. Pretend I say something clever here, something about drawing a business plan on a napkin, and how this metaphor is useful despite being simple.