?

Log in

No account? Create an account
Previous Entry Share Next Entry
When you make something from a Model, what is it?
device
jducoeur
Casting my net a little wider than the querki_project community for this one, since I'm looking for brainstorming.

Querki is trying (sometimes successfully, sometimes not) to avoid conventional programming jargon -- both because my concepts tend not to quite match the usual words, and simply to *sound* less like programming.

So I've got this concept that I call "Model". It's kinda-sorta like a "class" in object-oriented programming, although it's really more like a "prototype" in languages like Javascript. It's the basis we're using for a kind of Thing. Models are stuff like "Person", "Email Message", "Blog Entry" -- the abstract structures that you fill in to get something real.

What do we call those "something real"s, though? That is, what is the term for something that specifically *isn't* a Model, but is based on one? It's not "Thing" -- everything is a Thing, including Models. The technical term is "instance", but that *sounds* technical to my ear, and I would like to see if we can find an alternative. The only other idea I've had so far is "item", but that's a tad wishy-washy, and can get confused with list elements.

So -- anyone have suggestions? This is about to become real, since I'm about to add the method that is "all the non-Model instances that derive from this Model", and I'm trying to figure out what that is named...

ETA, so I don't lose track of it: over on Facebook, 'hannes mentioned the word "entity", which isn't half-bad. It has the right connotations of concreteness, and we're not doing anything else with the term...
Tags:

  • 1
In the programming, analysis and design world, "model" already has meaning.

"manifestation" has a nice Victorian ring to it....

Too long to be practical, I suspect, but I agree that it works nicely otherwise...

Slightly better than "realization"

Agree with first commenter that "model" already has meaning, in the model-view-controller (MVC) paradigm. I hadn't thought of it, but I also like manifestation as an alternative to instance. Or, exemplification could work, too. Though as verbs (okay, method names) to do your instantiation, I like Manifest better than Exemplify.

Hmm. Model also implies something that is looked at and copied to me. Where as the process here of starting with a structure and then modifying it... that's more like a Mold. It gives some structure to the raw materials you are working with, but like with molds for clay, you're not rigidly bound to the result, and after molding you can tweak, adjust, fill in, paint, combine, etc.

What do potters or metalworkers call the things that come out of molds? In some cases 'castings', but of course, casting is also a programming jargon, but sufficiently removed I think. Otherwise, the results seem to be called by what they are. Pots, vases, sculptures, etc. Results? Products? Outcomes?

Template? That's more for model than for instance.

Also, how quirky are you willing to have Querki become? Would you be interested in names like "thingamabob" and "doohicky", or are they insufficiently indicative of what they represent?

Thesaurus.com gave the following synonyms for instance: detail, example, exemplification, exponent, ground, illustration, item, occasion, occurrence, particular, precedent, proof, reason, representative, sample, sampling, specimen, time.

I like specimen, but that's probably too scientific for the average person. Example, sample, and occurrence all sound good, though occurrence is also likely too technical.

Here are the synonyms for model, in case you care: apotheosis, archetype, beau ideal, criterion, design, emblem, embodiment, epitome, exemplar, gauge, hero, ideal, lodestar, mirror, mold, nonesuch, nonpareil, original, paradigm, paragon, pattern, prototype, quintessence, role model, saint, symbol, touchstone, type.

I like archetype, probably also too technical, but that's kind of how I roll. Also, some of these would fit instance, such as exemplar and embodiment.

Okay, they gave me work to do, I need to go actually do it now.

Also, how quirky are you willing to have Querki become? Would you be interested in names like "thingamabob" and "doohicky", or are they insufficiently indicative of what they represent?

Well, given that Thing is already the most important noun in the entire system, I'm clearly willing to be quirky. But in practice, I suspect that going too far in that direction just produces its own incomprehensible jargon, which isn't the point.

I like specimen, but that's probably too scientific for the average person.

And more importantly, when the average person thinks of a "specimen", it has specific (and sometimes unpleasant) connotations of a doctor's office.

I like archetype, probably also too technical, but that's kind of how I roll.

In fact, it's a term I use frequently myself, and I agree that it suits quite well. Indeed, the original concept that the idea is based on is called "prototype". But as you say, both are a tad more technical than I'm aiming for here, which is why I went for Model -- reasonably similar to prototype in meaning, but more approachable.

I've read the current comments and really have nothing new to add. What I would caution, however, is that whatever terminology you finally adopt, it should be very apparent as to the hierarchy of (terms, items, things, whatchamacallits, stuff -- see, I don't even know what to call these pieces of thing that you are creating). If you're trying to get away from a jargon situation or a programming feel, then your terminology needs to be crystal clear and deducible by the user ... and it doesn't seem at the moment like it's going to be anywhere near that!

Which is my problem, yes. Getting that sort of extremely clear hierarchy isn't too difficult when you're aiming at *technical* or *scientific* users -- but doing so for the man in the street is bloody hard.

And worse comes to worst, I can change the terms used by end users later, if the community collectively decides that we want something better. But it's starting to get reified into code, so I'd like to make an effort now...

I don't know if I'm also too technical compared to the average person, but instance seems just fine for me and not a word that is only used in this context within programming.

To me an instance is just one specific happening out of a set of X similar happenings.

Hmm. Okay, that's a useful observation. It's possible that I am too close to the problem, and am over-thinking it. (After 40 years of programming, it is sometimes downright hard for me to tell what is and isn't obvious to a non-programmer -- which is why I need to get Querki up and running, so I can get folks to point out my blind spots.)

Thanks...

Interesting. Using it as a noun is unusual, but I've seen that usage before, and the meaning's about right. I'll chew on that -- thanks...

If you want, keep it as an adjective. You can have actual things, or real things. You can even have model things.

Power users might then shorten it to "actual" or "real" vs "model", but your documentation can use the two-word construction and be abundantly clear and intuitive.

+1. After a minute or two of pondering, this was the best notion I came up with.

(Arrived at by the time-honored method of "try to write an explaination for someone who doesn't quite understand the concepts and see what words come up".)

(Deleted comment)
It's plausible, although I'm reluctant -- Thing is already used (and laced *very* deeply through the code) with a broader meaning.

"Idea" is a reasonably good alternative to Model, but I'm not looking to change that today. (As I mentioned upthread, nothing's set in stone, but I don't have a lot of motive to change the term Model right this minute.)

Heather's observation about "instance" may yet win the day, but it occurs to me that the best word might actually be Object. Only problem is, that will *utterly* confuse the snot out of the programmers.

*Sigh* -- I had specific reasons to *not* use the term "Object" as the universal generic. (Which is what "Thing" is.) But I am starting to suspect it will prove to have been the wrong decision. I may have to ponder exactly how much of a pain in the ass it would be to change...

"I may have to ponder exactly how much of a pain in the ass it would be to change..."

If it is part of the exposed user interface, it *should* be easy to change since it will be in one place in a language file, yes?

It's an underlying concept, so I suspect it's not *that* well-centralized. Particular properties and such are all crisply defined, but I'm only so good at factoring concepts that are laced throughout like that. There are probably a scattered handful of locations, anyway. Even if I had proper localization, odds are that the term would appear in a number of places -- you can only factor UI so far.

And no, there isn't a language file yet -- truth is, I haven't even figured out the right approach for that yet. Querki's a curious kind of platform, and the vast majority of the UI is live data. At some point, I'm going to have to puzzle out how localization works in it, but there are a lot of priorities that have to come first.

(Yes, I know that this is evil. But there are plenty of those to tackle -- I'm not even starting to worry about that until I have a proper test suite first. The sad truth is that localization is probably an edge case for at *least* the first two years.)

But mostly I meant in terms of the Querki codebase and documentation. I'm sure that the term "model" is there a few hundred times, at least, between all the parameters, variables, methods and so on. Granted, I could change the UI without changing the implementation, but I suspect that's a recipe for pain in the long run...

How does "example" grab you?

On the technical level it's reasonable, but I think it'll confuse people -- most folks think of an "example" as something you copy, which is more or less what Model means...

I do tend to think of "Model" as Model/View/Controller, so I do think I'd find that usage confusing, especially since Querki is something I'd think about in MVC terms.

I used "Element" for your instances, but I don't really like it. I like Entity, I think.

Hmm. I confess, I hadn't even considered the MVC issue until this conversation.

Changing the term "Model" would be some pretty serious work -- that ship has mostly sailed long since -- so I'm going to have to reflect a while before I bite that off. But I'll take the point under advisement...

I don't see Instance as being terribly technical; certainly no more so than Entity (though that's fine, too.) To me, it only seems that way because it's used as a technical term in a lot of object-oriented languages, but so is Model, and you're using that differently here, too. Programming languages have grabbed a lot of perfectly ordinary words and given them very specific meanings in context, so if you commit to not using them for that reason, you may be avoiding terms that would sound natural to a non-technical user.

Thinking further about the Model/specific situation, I think part of the problem may be that in the world of ordinary things, models aren't commonly generic. You have a car model, and instances of that are cars. You have a machine part model, and instances of that are parts. I suppose you could look up CAD systems; maybe they have a common term that I'm not thinking of.

(Deleted comment)
My own thought, on reading your post, was that "frame" fits the usage, in the sense of framing a house. (But of course, "frame" has its own freight.)

I agree with laurion's view: "mold" is probably the right direction to go. You make a mold for a thing, and then the result is a model.

How do things get made? What's the noun? What's the verb? That will affect your terminology.

Factories manufacture goods. Producers produce products (ugh, what a sentence). Presses emit... um, something.

"Thing" and "entity" are both nicely general and are also normal English words. For some reason "item" isn't working for me for something that isn't physical, but I don't know why that is yet so it might just be my, err, quirk.

Entity is bad because of the whole database entity-relationship terminology. Model is MVC. Instance is not bad.

Manifestation is not a word I've heard applied to software before, although I've dealt with some pretty spooky code... ;P

  • 1