Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
DanCarey404 opened this issue Sep 16, 2020 · 15 comments · Fixed by #989

Comments

@DanCarey404
Copy link
Contributor

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

@rjyounes
Copy link
Collaborator

rjyounes commented Sep 16, 2020

See #188 for the naming conventions and larger issue.

@uscholdm
Copy link
Contributor

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
Copy link
Collaborator

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
Copy link
Contributor

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
Copy link
Collaborator

rjyounes commented Sep 18, 2020

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
Copy link
Contributor

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

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

@rjyounes
Copy link
Collaborator

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

@rjyounes rjyounes changed the title Refactor :hasTag as :tagText Review and refactor :hasTag and other text datatype properties Oct 13, 2020
@rjyounes
Copy link
Collaborator

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

@rjyounes
Copy link
Collaborator

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

@rjyounes rjyounes changed the title Review and refactor :hasTag and other text datatype properties Review and refactor :hasTag and other text datatype properties, and consider making uniqueText and tagText subproperties of containedText. May 13, 2022
@uscholdm
Copy link
Contributor

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

Makes sense at first blush.

@uscholdm
Copy link
Contributor

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.

@uscholdm
Copy link
Contributor

@rjyounes PROPOSAL (after reading this and related issues).

  • broaden range of containedText to include anyURI
  • Get rid of tagText use containedText instead. This entails changing the equivalentClass to subClass for the restriction for Tag
  • Add domainIncludes Tag and Text for containedText
  • uniqueText subproperty of containedText
  • remove reference to Text class in the definition of containedText, add examples

This has all been provisionally implemented on the branch: https://github.com/semanticarts/gist/tree/issue-372-text-datatype-properties

@rjyounes
Copy link
Collaborator

I like the proposal. The implementation looks good as well. Ready to run by the group.

@rjyounes
Copy link
Collaborator

Would you mind submitting a PR so this doesn't get lost in the long list of issues we are triaging? Please add it to project 12.1.0.

@uscholdm
Copy link
Contributor

I could, but I was waiting for approval before doing the release notes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

3 participants