Closed jbkoh closed 4 years ago
For the unit composition, I thought the users were composing units. If it’s part of Brick it shouldn’t be a problem.
@steveraysteveray How do you accomplish this in RDF? "When searching for something that has dimensionality of (power x time) or of (time x power), it won’t matter."
@jbkoh quantityKind (QUDT concept) refers to an equivalent type of measurement (ex: mass or temperature). A unit describes the conversion factors required to convert to a common common unit of measurement for a particular quantityKind (ex grams or Kelvin). A unit therefore belongs to one and only one quantityKind.
I’m really going out on a limb here, and haven’t even vetted this with colleagues, but if you start with the dimension vectors for power x time (which is energy), that is: Mass x Length2 / Time 2, then you can navigate to the units that have that dimensionality. Something like:
SELECT ?unit WHERE {
?s qudt:hasDimension ?dim .
?dim qudt:hasDimensionVector qudt:DV_USCUSTOMARY-L2 .
?dim qudt:hasDimensionVector qudt:DV_USCUSTOMARY-M1 .
?dim qudt:hasDimensionVector qudt:DV_USCUSTOMARY-T-2 .
?dim qudt:hasDimensionVector qudt:DV_USCUSTOMARY-H0 .
?dim qudt:hasDimensionVector qudt:DV_USCUSTOMARY-U0 .
?s qudt:applicableUnit ?unit .
}
…which returns all the units (in all the systems) that have that dimensionality. The point being that you aren’t searching for string matches.
Steven R. Ray, Ph.D.
Distinguished Research Fellow
Carnegie Mellon University
NASA Research Park
Building 23 (MS 23-11)
P.O. Box 1 Moffett Field, CA 94305-0001
Email: steve.ray@sv.cmu.edu
Phone: (650) 587-3780
Cell: (202) 316-6481
Skype: steverayconsulting
cid:A9ED74CE-68DA-4276-847C-3C08B21B97C0@wv.cc.cmu.edu
From: bbalaji-ucsd [mailto:notifications@github.com] Sent: Tuesday, September 26, 2017 3:16 PM To: BuildSysUniformMetadata/Brick Cc: steveraysteveray; Mention Subject: Re: [BuildSysUniformMetadata/Brick] RFC: Units (#26)
For the unit composition, I thought the users were composing units. If it’s part of Brick it shouldn’t be a problem.
@steveraysteveray https://github.com/steveraysteveray How do you accomplish this in RDF? "When searching for something that has dimensionality of (power x time) or of (time x power), it won’t matter."
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/BuildSysUniformMetadata/Brick/issues/26#issuecomment-332352255 , or mute the thread https://github.com/notifications/unsubscribe-auth/ABE-zQ6d20dblWD6CgHDl0dV5EY3XzG8ks5smXe6gaJpZM4Ob7gK .Image removed by sender.
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient Image removed by sender.
Virus-free. http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient www.avg.com
Thanks Steve! This does help a lot to understand how the unit ecosystem works.
Regards, Bharath
On Wed, Sep 27, 2017 at 10:03 AM, steveraysteveray <notifications@github.com
wrote:
I’m really going out on a limb here, and haven’t even vetted this with colleagues, but if you start with the dimension vectors for power x time (which is energy), that is: Mass x Length2 / Time 2, then you can navigate to the units that have that dimensionality. Something like:
SELECT ?unit WHERE {
?s qudt:hasDimension ?dim .
?dim qudt:hasDimensionVector qudt:DV_USCUSTOMARY-L2 .
?dim qudt:hasDimensionVector qudt:DV_USCUSTOMARY-M1 .
?dim qudt:hasDimensionVector qudt:DV_USCUSTOMARY-T-2 .
?dim qudt:hasDimensionVector qudt:DV_USCUSTOMARY-H0 .
?dim qudt:hasDimensionVector qudt:DV_USCUSTOMARY-U0 .
?s qudt:applicableUnit ?unit .
}
…which returns all the units (in all the systems) that have that dimensionality. The point being that you aren’t searching for string matches.
- Steve
Steven R. Ray, Ph.D.
Distinguished Research Fellow
Carnegie Mellon University
NASA Research Park
Building 23 (MS 23-11)
P.O. Box 1 Moffett Field, CA 94305-0001
Email: steve.ray@sv.cmu.edu
Phone: (650) 587-3780
Cell: (202) 316-6481
Skype: steverayconsulting
cid:A9ED74CE-68DA-4276-847C-3C08B21B97C0@wv.cc.cmu.edu
From: bbalaji-ucsd [mailto:notifications@github.com] Sent: Tuesday, September 26, 2017 3:16 PM To: BuildSysUniformMetadata/Brick Cc: steveraysteveray; Mention Subject: Re: [BuildSysUniformMetadata/Brick] RFC: Units (#26)
For the unit composition, I thought the users were composing units. If it’s part of Brick it shouldn’t be a problem.
@steveraysteveray https://github.com/steveraysteveray How do you accomplish this in RDF? "When searching for something that has dimensionality of (power x time) or of (time x power), it won’t matter."
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/BuildSysUniformMetadata/Brick/issues/26# issuecomment-332352255> , or mute the thread < https://github.com/notifications/unsubscribe-auth/ABE-zQ6d2 0dblWD6CgHDl0dV5EY3XzG8ks5smXe6gaJpZM4Ob7gK> .Image removed by sender.
http://www.avg.com/email-signature?utm_medium=email&utm_ source=link&utm_campaign=sig-email&utm_content=emailclient Image removed by sender.
Virus-free. http://www.avg.com/email-signature?utm_medium=email&utm_ source=link&utm_campaign=sig-email&utm_content=emailclient www.avg.com
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/BuildSysUniformMetadata/Brick/issues/26#issuecomment-332588743, or mute the thread https://github.com/notifications/unsubscribe-auth/ADFqQohW6usxlcGvHHP53Gh_BCJ6ESPBks5smn_ngaJpZM4Ob7gK .
@berkoben Hey Keith, it's been a while! Hope you are staying safe and healthy. I am finally trying to close this issue. What did you end up using in your project for units?
QUDT has come a long way since we had this discussion, and it's what we should probably be using
@gtfierro interesting that you repeat what I said.
https://github.com/BrickSchema/Brick/pull/131 contains the latest strawman prototype of incorporating units into Brick. Still some work to be done, but it seems appropriate to move this conversation there, given the changes in QUDT and Brick since this original issue was raised
How should Brick represent units?
This RFC continues this
Introduction Unit is a primary metadata to interpret/process data modeled with Brick. There was multiple requests to integrate units with Brick and there is no reason not to adopt it. However, designing every possible unit is not a feasible way as there are i) numerous units, ii) variations for same property (C vs F), and iii) various standards. Along the line I propose below:
Proposal
(1) Structure: We limit only Point to have a unit. As discussed in the thread, Points directly having a unit is sufficient enough for systems we modeled. (2) Vocabularies: The vocabularies are adopted from QUDT.
Required tasks (1) Add hasUnit property to BrickFram.ttl (2) Select units from QUDT (especially related to BACNet) and include them in Brick.ttl (or BrickUnit.ttl if necessary.) (3) Write units not defined in QUDT but in BACNet by using the related existing units. E.g., FT3-PER-MIN given FT-PER-MIN. (We could also add explicit definition of FT3-PER-MIN in the ontology.)
Discussions (1) Unit changes across time: It is not included in the current proposal, but we could specify a unit to have a valid prediod (but needs another instantiation.) E.g., "DEG_F-1 begins 2017/1/1" and "DEG_F-1 ends 2017/1/31". It's a possibility with the current structure but again not included in this RFC. (2) There can be an argument that we should use less ambiguous words (e.g., Fahrenheit) to represent units and directly adopting QUDT vocabularies. However, some ambiguity is unavoidable unless we use full sentences to express units. I suggest to let QUDT community to handle it and we use them directly. In fact, there is no common standard for all kinds of units and any unit standard has similar problem. (3) Same argument for consistency issue as (2). Not all of QUDT vocabularies are consistent. E.g., KW and KillW-HR. I would let QUDT (4) QUDT version 2 is under revision so not all of the vocabularies are (4) Alternative vocabularies: UCUM: more consistent but less comprehensive and less expressive.