Formal definition of ServiceSpecification is wrong

[rjyounes]

Formal definition of ServiceSpecification is:

gist:ServiceSpecification
	a owl:Class ;
	owl:equivalentClass [
		a owl:Class ;
		owl:intersectionOf (
			gist:CatalogItem
			[
				a owl:Restriction ;
				owl:onProperty [
					owl:inverseOf gist:isBasedOn ;
				] ;
				owl:someValuesFrom gist:Event ;
			]
		) ;
	] ;
.

That is, a catalog item that has some event based on it.

However, like any specification or template, there need not be anything yet in existence that is based on it. Note that neither the superclass Specification, any of its other subclasses, or the Template and TaskTemplate classes make this invalid assumption.

The challenge will be in finding another restriction to complete a "distinctionary" definition; thus the absence of restrictions on the other specification classes.

[rjyounes]

Perhaps it's as simple as replacing Event with EventSpecification.

[rjyounes]

gist dev team meeting 10/27/25:

Rebecca: ServiceSpecification could be the intersection of CatalogItem and EventSpecification. Or we could eliminate ServiceSpecification and just use EventSpecification instead.
Dan: EventSpecification is so broad that we shouldn't replace ServiceSpecification with it.

Dave: Should ServiceSpecification subclass CatalogItem? That excludes, e.g., our proposals to potential customers.
Include in the definition of CatalogItem that it's non-negotiable, off-the-shelf. (Price may be negotiable but the item isn't.)
CatalogItem is offered to anyone, whereas a ServiceSpecification may be customized to an individual customer.

Dylan: The current definition of CatalogItem is too broad. There are instances of both ProductSpecification and ServiceSpecification that are not instances of CatalogItem. Dave gave an example for ServiceSpecification. An example for ProductSpecification: If I sell my car and put the specs in the bill of sale, it seems obvious to me that there's a product specification there, but I have no catalog of products and consequently no catalog item.
Rebecca: There's a catalog item for a product, not a product specification. But CatalogItem doesn't formally specify what it's a description of, so that should be OK.

Rebecca: If ServiceSpecification does not subclass CatalogItem, we need another way for it to specialize EventSpecification.
Dave: Specialization is that it describes something that will be offered. Whereas EventSpecifications are not necessarily offered (hurricanes, etc.)
Rebecca: How would we formalize that?

To be continued at next meeting.

[dylan-sa]

(Expanding on my thoughts from yesterday's meeting.)

I agree that the definition of ServiceSpecification should be modified.

On the related discussion of CatalogItem:

The current definition of CatalogItem is too broad. There are instances of both ProductSpecification and ServiceSpecification that are not instances of CatalogItem. Dave gave an example for ServiceSpecification. An example for ProductSpecification: If I sell my car and put the specs in the bill of sale, it seems obvious to me that there's a product specification there, but I have no catalog of products and consequently no catalog item.

One could maintain that even though the car spec isn't actually in a catalog, the important point is that it could be (e.g., if it were posted for sale in an online catalog). If that's the intent, we should document in the annotations.