question: non-volumetric quantitykind:NumberDensity

[justin2004]

Hello,

quantitykind:NumberDensity covers "count per volume."

But what covers "count per area" and "count per length?"

[steveraysteveray]

I'll try to think more deeply about this tomorrow, but my thought is that "density" is normally interpreted as "volumetric density". The other cases can be "area density" and "linear density", so we could define those quantitykinds, as well as derived terms. Trying to think of natural sounding names... "AreaNumberDensity"? "LinearNumberDensity"?

In addition to the dimensionality question above, we still have the question of what the denominator is. The normal interpretation is volume, but we have also touched upon notions of mass density - i.e. things per unit mass. We should think about a systematic, yet intuitive way of handling all of this.

[justin2004]

hi @steveraysteveray ,

those names sound good to me. i just added these to wikidata which would be companions to what we are talking about here: linear number density areal number density

it is probably too late to change it but i think quantitykind:NumberDensity might be better called something like volumetric number density.

what the denominator is

when it comes to generic Number Density i think the denominator is something like "range of concern..." which could be a volume, an area, a length, etc.

[jhodgesatmb]

From the initial email it seemed as though the count was the important thing. I cannot imagine a case where a density would be associated with a length or area, but I can surely see a count being associated with an area or length. So maybe we should be looking at ways to name an area count or a length count that don't include the term density at all.

Jack

On Sun, Oct 17, 2021 at 8:32 AM justin2004 @.***> wrote:

hi @steveraysteveray https://github.com/steveraysteveray ,

those names sound good to me. i just added these to wikidata which would be companions to what we are talking about here: linear number density https://www.wikidata.org/wiki/Q108914968 areal number density https://www.wikidata.org/wiki/Q108914965

it is probably too late to change it but i think quantitykind:NumberDensity might be better called something like volumetric number density https://www.wikidata.org/wiki/Q176449.

what the denominator is

when it comes to generic Number Density https://www.wikidata.org/wiki/Q108914962 i think the denominator is something like "range of concern..." which could be a volume, and area, a length, etc.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/qudt/qudt-public-repo/issues/440#issuecomment-945145606, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATQRWJ5HJPTLH77LQRWTADUHLT77ANCNFSM5GE4PCDQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Jack

[justin2004]

I cannot imagine a case where a density would be associated with a length or area

I think this is less about density being associated with length or area but rather the density is partially derived from area or length such as: population density == (count of inhabitants / area occupied).

[jhodgesatmb]

In that case we should go with what the international standards say, if they say anything, and then go with the colloquialism. In the end the label is just an annotation and the qname, unit, and dimension vector are more important because they are unambiguous.

Jack Hodges, Ph.D. Arbor Studios

On Oct 17, 2021, at 2:13 PM, justin2004 @.***> wrote:

 I cannot imagine a case where a density would be associated with a length or area

I think this is less about density being associated with length or area but rather the density is partially derived from area or length such as: population density == (count of inhabitants / area occupied).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[dr-shorthair]

count per area and per length comes up in ecology surveys

[justin2004]

@steveraysteveray

In addition to the dimensionality question above, we still have the question of what the denominator is. 
The normal interpretation is volume, but we have also touched upon notions of mass density - i.e. things per unit mass.
We should think about a systematic, yet intuitive way of handling all of this.

BFO talks of ZeroDimensionalSpatialRegion, OneDimensionalSpatialRegion, TwoDimensionalSpatialRegion, ThreeDimensionalSpatialRegion, and generally SpatialRegion.

So "count per Spatial Region" might be the general thing and specializations of that might include "count per One Dimensional Spatial Region" which is "count per length," etc.

I am not sure what the formal math-y way of saying Spatial Region is though.

[jhodgesatmb]

Interesting idea, but if we go this way we open the door for similar concepts. Does BFO identify non-spatial concepts?

Jack Hodges, Ph.D. Arbor Studios

On Oct 17, 2021, at 4:57 PM, justin2004 @.***> wrote:

 @steveraysteveray

In addition to the dimensionality question above, we still have the question of what the denominator is. The normal interpretation is volume, but we have also touched upon notions of mass density - i.e. things per unit mass. We should think about a systematic, yet intuitive way of handling all of this. BFO talks of ZeroDimensionalSpatialRegion, OneDimensionalSpatialRegion, TwoDimensionalSpatialRegion, ThreeDimensionalSpatialRegion, and generally SpatialRegion.

So "count per Spatial Region" might be the general thing and specializations of that might include "count per One Dimensional Spatial Region" which would is "count per length," etc.

I am not sure what the formal math-y way of saying Spatial Region is though.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[steveraysteveray]

OK, here's what I propose:

For quantitykinds of length denominator:

1. NumberDensity (because this is the "normal" interpretation, we should use this familiar name, with an owl:sameAs VolumetricNumberDensity. This is consistent with our current practice of not qualifying the normal interpretation of other terms, such as "Density", which normally means mass per unit volume. We have an owl:sameAs with MassDensity, so in a similar way, we could have NumberDensity owl:sameAs VolumetricNumberDensity)
2. AreaNumberDensity (recommend this rather than ArealNumberDensity because the latter might be misinterpreted as "A Real Number Density"). Also owl:sameAs ParticleFluence
3. LinearNumberDensity (per earlier comments, this is used not just in ecology, but as "dpi" to describe screen resolutions). This should be owl:sameAs InverseLength, which is currently defined.

For quantitykinds of mass denominator:

1. NumberPerUnitMass (we already have AmountOfSubstancePerUnitMass, so this is consistent) I'm not aware of a need for NumberPerSquareMass, but if the need exists we could add that, plus higher orders.

[justin2004]

I think that sounds pretty good to me.

we could have NumberDensity owl:sameAs VolumetricNumberDensity

+1

Also, quick question about quantitykind:InverseVolume ... about it QUDT says:

qudt:baseUnitDimensions "\\(/m^3\\)"^^qudt:LatexString

Is that saying "1/m^3" ? (That is what I would expect.) If so why is the 1 missing? I don't know LaTex.

Also, I'm curious how we got here. When quantitykind:NumberDensity was coined as "count per volume" should we have paused and said something like "Hey, 'count' is sort of unique and elemental but 'volume' is a member of a family of ideas like 'length,' 'area,' etc. ... should we make room for them too?"

I don't mean this question in an accusatory way either. I work with a team that is developing an ontology and I am looking for rules of thumb to know when we've appropriately accommodated future use (that is, representations that people will need/want to make but that we just don't know about yet).

[justin2004]

About the "Also, I'm curious how we got here."

I realized after writing that that QUDT already had ParticleFluence and InverseLength but it wasn't immediately clear to me that those were equivalent to AreaNumberDensity and LinearNumberDensity, respectively.

Maybe that is mostly on me but it does seem like an ontology should help nudge users to the thing they are looking for.

I approached QUDT looking for different flavors of NumberDensity and that didn't lead me to ParticleFluence and InverseLength.

[steveraysteveray]

An easy way for a first cut is to use the EDG interface. Here's a screen shot where I looked up NumberDensity, followed the link to the dimension vector, and brought up the References pane:

This view shows me all the Units and QuantityKinds that have that dimension.

Another way to explore is to look at InverseLength in the same way, and observe the skos:broader references as well as the referring units:

And yet a third way is to throw the following query into our SPARQL endpoint at https://qudt.org/fuseki

PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX qk: <http://qudt.org/vocab/quantitykind/>
PREFIX unit: <http://qudt.org/vocab/unit/>
PREFIX constant: <http://qudt.org/vocab/constant/>

SELECT *
WHERE {
  ?subject owl:sameAs ?object
}
LIMIT 25

...which gives: