Duplicate unit for kilopond #545
-
Kilopond is defined as both |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 5 replies
-
If both are "commonly expected" URIs, we have been relating them with owl:sameAs. We kind of want to avoid this as much as practical, though. In this particular case, the alternative is to retire one of them, at the risk of breaking user's existing implementations. When inventing new units, you have already seen our naming guidance in the wiki, I believe. That is one place where the naming rules might not produce the intuitive name, in which case we add both with owl:sameAs. |
Beta Was this translation helpful? Give feedback.
-
Indeed, there are good arguments for either one. We have not come to closure on picking one, or staying with both. |
Beta Was this translation helpful? Give feedback.
-
Are the axiomatizations identical? |
Beta Was this translation helpful? Give feedback.
-
It isn’t an issue of whether a unit is in vogue but, rather, if it is in any of the standards supported by QUDT. If it isn’t, and was contributed by someone, then an argument can be submitted to that contributor asking if they are aware that their unit is obsolete (and of course providing documentation of same). If it is in a standard then we could remove it if the standard removes it. We are, sometimes, falling behind with the standards.
Jack Hodges, Ph.D.
Arbor Studios
… On Aug 18, 2022, at 9:50 AM, Matt Goldberg ***@***.***> wrote:
Right, I am familiar with the naming rules. The wiki actually says to use qudt:exactMatch, but I see both that and owl:sameAs are in use. Do you plan to standardize to one of those at some point?
For this particular case, do you believe that unit:KiloP and unit:KiloPOND are both "commonly expected" enough to add qudt:exactMatch or owl:sameAs instead of retiring one given that the kilopond is generally considered obsolete?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
|
Beta Was this translation helpful? Give feedback.
-
My opinion remains the same. If the standards have it we should keep it. If
not we can do what we want (as long as the community backs us). What would
be inadvisable is to go back and forth with units, quantity kinds, etc.,
adding and removing depending on what is considered to be in/out of vogue.
Clearing up possible confusion (e.g., Pascal) is certainly to be attempted.
We are talking about qnames here so maybe it is a moot point.
…On Tue, Aug 23, 2022 at 8:01 AM steveraysteveray ***@***.***> wrote:
Personally, I'm willing to retire unit:KiloP and keep unit:KiloPOND. My
rationale is that KiloP might be confused to mean Kilo Pascal as a unit of
pressure. I would keep KiloPOND for historical value.
What say others?
—
Reply to this email directly, view it on GitHub
<#545 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AATQRWJNHUKCVHIRG3JWIVLV2TRUXANCNFSM5653EZNA>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
Jack
|
Beta Was this translation helpful? Give feedback.
If both are "commonly expected" URIs, we have been relating them with owl:sameAs.
We kind of want to avoid this as much as practical, though. In this particular case, the alternative is to retire one of them, at the risk of breaking user's existing implementations.
When inventing new units, you have already seen our naming guidance in the wiki, I believe. That is one place where the naming rules might not produce the intuitive name, in which case we add both with owl:sameAs.