-
Notifications
You must be signed in to change notification settings - Fork 18
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
Comments
See #188 for the naming conventions and larger issue. |
A slight problem with |
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. |
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:
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
|
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. |
I guess you mean an explicit subclass, rather than only by inference. |
No, I mean either. My statement was unclear, so I've fixed it above. |
Note that the property has already been renamed to |
Actually, |
Makes sense at first blush. |
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. |
@rjyounes PROPOSAL (after reading this and related issues).
This has all been provisionally implemented on the branch: https://github.com/semanticarts/gist/tree/issue-372-text-datatype-properties |
I like the proposal. The implementation looks good as well. Ready to run by the group. |
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. |
I could, but I was waiting for approval before doing the release notes. |
In conformance to our naming standard, we should refactor the data property :hasTag as :tagText or something similar.
The text was updated successfully, but these errors were encountered: