Review and refactor :hasTag and other text datatype properties, and consider making uniqueText and tagText subproperties of containedText.

[DanCarey404]

In conformance to our naming standard, we should refactor the data property :hasTag as :tagText or something similar.

[rjyounes]

See #188 for the naming conventions and larger issue.

[uscholdm]

A slight problem with tagText, is the possibility of being misled into thinking it s an object property with range: gist:Text (which just happened to me). A plain noun is our convention, which would suggest the property be called just "tag" but that is not so appealing.

[rjyounes]

We currently have three datatypes properties of the form XText: uniqueText, containedText, and encryptedText, subproperty of containedText. The definition of contained text is "links to the string corresponding to Text." I don't know if the capital T is meant to indicate a domain of Text, but the property has no formal domain. At any rate, the final "Text" does not indicate a range of Text, so "tagText" is not any more misleading than terms we already have.

I propose using containedText for Tag as well as Text, and cleaning up the definition to remove reference to the Text class. uniqueText could then also be a subproperty of containedText.

[uscholdm]

Good points. I withdraw my concern about tagText.

If you use containedText instead of tagText, then the definition says that every Category with containedText is a Tag, which does not seem right to me. Here we may have a collision of ontology guidelines/preferences:

1. we like fewer properties
2. we like formal definitions

In this case, to make the formal definition work you have to add a new property. Trying to semantically nail down just what a tag is might be a fools errand. A tag is as a tag does. For reference, here is the definition of gist:Tag

gist:Tag
	a owl:Class ;
	rdfs:label "Tag"^^xsd:string ;
	rdfs:comment "This is for folksonomy type terms, which can be made up on the fly by users."^^xsd:string ;
	owl:equivalentClass [
		a owl:Class ;
		owl:intersectionOf (
			gist:Category
			[
				a owl:Restriction ;
				owl:onProperty gist:hasTag ;
				owl:someValuesFrom xsd:string ;
			]
		) ;
	] ;
	.

[rjyounes]

Good point. We might consider whether Tag should not be a subclass of Category. Although they're both classification mechanisms, the fact that one is part of a controlled vocabulary and the other isn't is a potential basis for a formal distinction. The existing class hierarchy is semantically somewhat imbalanced, because all the other subclasses of Category are controlled vocabularies in different domains. Then you have Tag, which is a subclass for an entirely different reason.

[uscholdm]

We might consider whether Tag should be a subclass of Category.

I guess you mean an explicit subclass, rather than only by inference.
.

[rjyounes]

No, I mean either. My statement was unclear, so I've fixed it above.

[rjyounes]

Note that the property has already been renamed to tagText - other issues to be discussed and should be considered in relation to #594.

[rjyounes]

Actually, uniqueText and tagText are not presently subproperties of containedText, but arguably should be.

[uscholdm]

Actually, uniqueText and tagText are not presently subproperties of containedText, but arguably should be.

Makes sense at first blush.

[uscholdm]

I tend to like the idea of a Tag being a subclass of Category. Categories come in different flavors, some are statuses, some are types, some are tags.