Should gist:Template be a subclass of gist:Specification?

[uscholdm]

A template for something is very much like a specification (in the English sense of the word) for something in that both strongly influence what the nature of the something is or can be. Thus, perhaps gist:Template should be a subclass of gist:Specification.

[uscholdm]

FROM DAVE:
In my mind the difference is the spec establishes acceptance criteria. That is you can use them to determine where the service "complied" independent of how it was done. The taskTemlate/template task is about genericity: that is how can you create a set of instances that might satisfy the spec.

It's easy to imagine generating a set of tasks from a template that's when executed fails to achieve the spec.

Let's say the spec was 95% up time, and the template task was " generate a help desk ticket when someone complains"

That template may, or, may not, satisfy the spec

[uscholdm]

The text definition of gist:Specification currently is: "A set of requirements to be satisfied by a material, design, product, or service." It is a subclass of gist:Requirement which is a subclass of gist:Intention.

Broadly speaking, requirements and specifications come in many different flavors. Some dictate what the shape/structure of something must be (a form to fill in) others dictate performance criteria (95% up time), still others dictate state criteria (acidity level). A specification may include any or all of these kinds of requirement.

A form is a template which can be viewed as a specification requiring the filled document be of a certain shape/structure. While we would not normally say that the form is a [set of] requirement[s] for the document, it does in fact dictate a whole lot about what the document is required to be like.

Long before gist had a class for Specification, I created one and gave it a more inclusive definition than the current one; Template was a subclass (see below). When Dave created an 'official' gist:Specification some years later, he chose a narrower interpretation, and Template was not a subclass.

I think it is a legitimate option to broaden the skos:definition of gist:Specification to include a wider range of things that are reasonably thought of as specifications (such as Templates). We can just change the English and cause minimal impact.

If we leave it as it is, then we fail to capture the similarity between Template and Specification.

MY ORIGINAL DEFINITIONS from a few years ago.

Here was my original inclusive definition, created with great care and thoughtfulness :
"A body of information specifying what properties, structure and/or results something should or must have after it has been built, fulfilled or completed. The thing may be physical (a building), organizational (a management structure), computational (a program), job or task related (e.g., a CEO, Chief Judge) or changing oil in a car. "

The define of Template (a subclass of Specification) was:
"A structure that is used as the basis for generating new individuals that have that structure, e.g., a form. A filled-in form has the structure of the form with data entered into some or all of the fields."

[rjyounes]

@uscholdm to prepare brief presentation for discussion on January 30.

[rjyounes]

A Template is used to make something that follows a specification.

[uscholdm]

I agree, but see my long comment above for the history of the term 'Specification' in gist.

Those definitions can be found here:
S:\ClientsAndPartners\Sentara_Enterprise_Ontology\EntOnt\Version1.0\Final Deliverables\OWL Files\upper1.0.owl

The definition for Specification probably evolved a bit in subsequent projects at Broadridge and Schneider.

[uscholdm]

Summary of group discussion on 12-Nov-20

Documented by @uscholdm

Before getting into whether a Template is a Specification, we addressed whether the scope of Specification was too narrow.

Is the meaning of gist:Specification too narrow?

• Consensus was emerging to expand the meaning of gist:Specification beyond acceptance criteria regarding what something is. This meaning is common in computing (e.g. a program specification) and is appropriate for products. A braoder interpretation of the term, specification, would include the specification of how to do something, which would include things like plan, process, method, recipe.

• A place to start is the following definition from a prior gist

  • "A body of information specifying what properties, structure and/or results something should or must have after it has been built, fulfilled or completed. The thing may be physical (a building), organizational (a management structure), computational (a program), job or task related (e.g., a CEO, Chief Judge) or changing oil in a car."

• The question arises (but was not discussed at any length) as to whether there should be two main subclasses, as follows.

  • one for the acceptance criteria meaning which focusses on what something is
  • the other has a focus on how to do something. Cyc used the term `normative specification' for this.

Is a Template itself a Specification?

• There were mixed views on whether gist:Template should be a subclass of gist:Specification. Below are two definitions of gist:Template. The first is current, the second is a former definition.

  • "Something used to make instances in its own image. In manufacturing this would be specialized as a die to make stamped parts, cookie cutters are templates for cookies, and forms are templates for data."
  • "A structure that is used as the basis for generating new individuals that have that structure, e.g., a form. A filled-in form has the structure of the form with data entered into some or all of the fields."

• It was noticed that a template may be a tool that is used to create something that meets a specification. This could be true of a manufacturing die or cookie cutter. In those cases, there may well be a specification in the form of a CAD drawing. And you could view the die and cookie cutter as physical embodiments of their respective specifications. But templates can also be fashioned directly from ones imagination; there may not be any specification that came before the template for the template to conform to. The question arises:

  • Is a die (or cookie cutter) itself a specification, or just the physical embodiment of a specification.
  • If it just the physical embodiment of the specification, and not a specification, then Template cannot be a subclass of Specification.
  • Would we want to have two individuals: one the specification and one the embodiement that is linked to the specification?
  • This reminds me of the fact that a statue can cease to exist after it is melted down, but the metal still does exist. So strictly, speaking, there must be two separate individuals. But in practice do we really care about that distinction enough to want both?

• What about forms? A form is a template, and normally there would not be a specification that it would be embodying or helping to meet. The form itself could be viewed as a specification for what a set of information should look like (a filled out form).

Specifications, Templates and Artifacts

• Should Template be an orphan? If Template is not a Specification, then what is it? Template the definition of gist:Artifact, which is an intentionally made thing, made by people (possibly indirectly via machines). So in any event, Template should be a subclass of Artifact.
• Should Specification also be a subclass of Artifact? Well, it is also an intentionally made thing, so I'd say yes.
• Should Intention also be a subclass of Artifact? If Specification is an Artifact, then perhaps Intention is too? It seems so. We can probably finesse our way out of having a circular definition defining Intention in terms of intention.

[rjyounes]

@uscholdm Thanks for the great summary of our length discussion yesterday. I had a thought about the discussion about Template subclassing Specification: suppose the cookie cutter gets dented. We don't say the specification is defective, we say the template no longer meets the specification. This bolsters the idea that a Template is not a Specification, but a tool for implementing the Specification.

This issue has undergone significant scope creep. The original issue was:

1. Should Template be a subclass of Specification?

We have added an additional 3 issues which are related but not inseparable:
2. Should the definition of Specification be expanded to include process specifications?
3. Should Template be an orphan or assigned to some other superclass? (Since Template currently is an orphan, this is a new issue.)
4. What are the proper relationships between Template, Specification, and Artifact? (and can we prevent Artifact from becoming an orphanage?)

I propose that we deal with the original issue here, and create separate issues for the others: 2 should be its own issue, and 3 and 4 should be rolled into a single issue. Granted that our original issue relates closely to 3 and 4, it can be decided independently, before tackling the other subclassing issues as a whole.

@uscholdm and others involved in yesterday's discussion - @Jamie-SA @marksem @sa-bpelakh - let me know if you're in agreement and I'll create the two additional issues.

My view on 1 is that Template is a tool to implement a Specification rather than a Specification, so it should not be a subclass, and that as part of addressing the current issue, we should modify the human-readable definition accordingly.

Trying to keep these issues to bite-sized chunks as much as possible, I would also like to propose yet another issue to add a restriction to Template requiring it to relate to a Specification in some way. I'm not sure what the predicate would be, and we might need a new one, something like conformsTo or implements. I think I had