Remove equivalence to a union class from Artifact definition

[rjyounes]

When a class is defined as the union of a set of other classes, it is not possible to define additional subclasses. Is this by intention? It makes extension difficult.

For example:

	<owl:Class rdf:about="&gist;Artifact">
		<rdfs:label rdf:datatype="&xs;string">Artifact</rdfs:label>
		<rdfs:comment rdf:datatype="&xs;string">An intentional person made thing, could be physical or content</rdfs:comment>
		<owl:intersectionOf rdf:parseType="Collection">
			<owl:Class>
				<owl:unionOf rdf:parseType="Collection">
					<rdf:Description rdf:about="&gist;Content">
					</rdf:Description>
					<rdf:Description rdf:about="&gist;IntellectualProperty">
					</rdf:Description>
					<rdf:Description rdf:about="&gist;Equipment">
					</rdf:Description>
					<rdf:Description rdf:about="&gist;Building">
					</rdf:Description>
					<rdf:Description rdf:about="&gist;PhysicalSubstance">
					</rdf:Description>
				</owl:unionOf>
			</owl:Class>
			<owl:Restriction>
				<owl:onProperty rdf:resource="&gist;goal"/>
				<owl:someValuesFrom rdf:resource="&gist;Function"/>
			</owl:Restriction>
		</owl:intersectionOf>
	</owl:Class>

Because this is a closed list, an ontology importing gist cannot define another direct subclass of Artifact.

In fact, we see already this problem within gist itself. System is a subclass of Artifact, but it is not asserted to subclass any of the unioned classes. Do we really want to say that System is a direct subclass of one of these, but we don't know which? Seems odd. And none of the unioned classes seem like appropriate superclasses of System.

[uscholdm]

For most practical purposes you are right. But technically, this pattern does not prevent further sub-classing. Its fine, so long as any further subclasses are fully a subset of the union. This pattern arises in a number of places in gist. It mainly results from the author’s preference for equivalence definitions over being certain that what is being stated is necessarily true. The idea is, if it turns out to be false, the definition can change at that time. I am not a fan of this approach. From: Rebecca Younes <notifications@github.com> Sent: Friday, 20 September, 2019 07:25 To: semanticarts/gist <gist@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: [semanticarts/gist] gist union constrains prevent further subclassing (#110) When a class is defined as the union of a set of other classes, it is not possible to define additional subclasses. Is this by intention? It makes extension difficult. For example: <owl:Class rdf:about="&gist;Artifact"> <rdfs:label rdf:datatype="&xs;string">Artifact</rdfs:label> <rdfs:comment rdf:datatype="&xs;string">An intentional person made thing, could be physical or content</rdfs:comment> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <rdf:Description rdf:about="&gist;Content"> </rdf:Description> <rdf:Description rdf:about="&gist;IntellectualProperty"> </rdf:Description> <rdf:Description rdf:about="&gist;Equipment"> </rdf:Description> <rdf:Description rdf:about="&gist;Building"> </rdf:Description> <rdf:Description rdf:about="&gist;PhysicalSubstance"> </rdf:Description> </owl:unionOf> </owl:Class> <owl:Restriction> <owl:onProperty rdf:resource="&gist;goal"/> <owl:someValuesFrom rdf:resource="&gist;Function"/> </owl:Restriction> </owl:intersectionOf> </owl:Class> Because this is a closed list, an ontology importing gist cannot define another direct subclass of Artifact. In fact, we see this problem within gist itself. System is a subclass of Artifact, but it is not asserted to subclass any of the unioned classes. Do we really want to rely on the open world assumption within the ontology, and say that System is a direct subclass of one of these, but we don't know which? Seems odd. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#110?email_source=notifications&email_token=ACSHHSI3OOUZUJU2Y5EBW3LQKTML7A5CNFSM4IYXW2Z2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HMWGI7Q>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ACSHHSJFXFENYJM6DU6WCE3QKTML7ANCNFSM4IYXW2ZQ>.

[rjyounes]

I should have been more explicit: you cannot do this without creating bad inferences unless the new subclass is properly contained in the union; that is, if I want to define a new top-level subclass of Artifact that is disjoint from the others.

Because the ontology is publicly available, it doesn't help to say that we'll change the definition later if we find another subclass. A user may want to add a subclass and does not have the freedom to modify gist itself.

[uscholdm]

I agree From: Rebecca Younes <notifications@github.com> Sent: Saturday, 21 September, 2019 05:22 To: semanticarts/gist <gist@noreply.github.com> Cc: Michael Uschold <uschold@gmail.com>; Comment <comment@noreply.github.com> Subject: Re: [semanticarts/gist] gist union constraints prevent further subclassing (#110) I should have been more explicit: you cannot do this without creating bad inferences unless the new subclass is properly contained in the union; that is, if I want to define a new top-level subclass of Artifact that is disjoint from the others. Because the ontology is publicly available, it doesn't help to say that we'll change the definition later if we find another subclass. A user may want to add a subclass and does not have the freedom to modify gist itself. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#110?email_source=notifications&email_token=ACSHHSNSREQGYNTVB6E4V5DQKYGWXA5CNFSM4IYXW2Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7IQYNQ#issuecomment-533793846>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ACSHHSO4VRX2Y2Z2Q26CO7LQKYGWXANCNFSM4IYXW2ZQ>.

[rjyounes]

Scott suggests using subclassing.

PhysicalSubstance is not necessarily person-made - we definitely want to remove this.

It's not a natural grouping.

Is Artifact the right label?

What is the purpose of having Artifact as a class? What was the rationale for adding it? It's an abstraction, like SocialBeing, which was eliminated for that reason. I.e., you would never instantiate it instead of one of its subclasses.

Artifact is an example of a larger problem. There is a design style issue. We'd have to examine all other union classes and decide on a case-by-case. Or we could rule out this pattern of equivalentClass to a union altogether.

Scott will take this on and bring back a proposal for a definition of Artifact.

Make new issue for the general design question.