Subject: [Asdf] Representation issues and protocol bindings

From: Carsten Bormann <[email-masked]>
Date: Mon, 31 Aug 2020 16:25:50 +0200

In today’s OneDM call, Bruce Nordman brought up the issue that, in the end, we’ll need concrete representations to talk to devices and use their data.

So if we have one ecosystem that uses 0..100 for describing the brightness setting for a lamp, another one that uses 0..254 (where 255 means something complete different), and a third with 0..65535, what do we do?  (And these might also differ whether they describe a emitted light power level or a perceptive luminous flux level.)

The underlying problem is that we are abusing data model level description techniques (in part borrowed from json-schema.org) to describe information models.
That works reasonably well until we start taking these data model level descriptions at face value.  The fact that some converged model uses a scale based on the L component of Lu’v’ does not mean that everybody has to represent their ecosystem model the same way.

The obvious second problem is that we haven’t tackled a framework for describing protocol bindings (which, initially, will mostly be ecosystem bindings).  That would be the place where we say how the L component needs to mapped to the ecosystem specific concrete representation.  Since that mapping, in principle, can have arbitrary complexity, completely covering all cases requires Turing-equivalent functionality in a description language.  Or we could go for an 80 % solution and then, for the 20 %, register mapping components that are more complex in an IANA registry.

Let’s discuss this based on some real-world examples — it is easy to construct artificial ones that have more complexity than we actually need.

CCing T2TRG as well because quite a few people there are familiar with the problem; maybe we want to have the bulk of the discussion on [email-masked] though.

Grüße, Carsten

---

From: "Wouter van der Beek (wovander)" <[email-masked]>
Date: Mon, 31 Aug 2020 14:50:38 +0000

Hi Carsten,

I think using JSON as a notation actually helps,
It avoids using the more precise thus more prescriptive  int32/64/... data types.
e.g. just Boolean, number and integer as base.

Enum values I hope everyone will start using string value as enum value, where the string can have an actual meaning, e.g. 
State = ["stopped, "running", "broken"] instead of [1,2,3] ...

As example I think brightness should be expressed as % in number so that one can choose its precision on the wire.
All examples of 0-254, 0-100, 0..65535 Are ok with me with a specific mapping.
So if one encounters the brightness on system A one should know the actual data on the wire so that one can map it to the oneDM model in SDF. If one needs to use it on system B, one needs to know how to write the data on the wire for System B.
(note that this only works when everything can be mapped linear, so even this simple example is not that simple).

And if there is a need (e.g. origin from an contributing org) we can add the more precise int32 as sub type.
But I think we all experienced that over time resolutions go up, good example of this is RGB,  0-255- 8 bits, then 16 bits, 24 bits ...

So I rather would go for the 80% solution, which is already 80% more than what is there today.

Kind Regards,
Wouter

-----Original Message-----
From: ASDF <[email-masked]> On Behalf Of Carsten Bormann
Sent: Monday, August 31, 2020 3:26 PM
To: [email-masked]
Cc: One Data Model Group <[email-masked]>; [email-masked]
Subject: [Asdf] Representation issues and protocol bindings

Grüße, Carsten

-- 
ASDF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asdf

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 31 Aug 2020 16:58:34 +0200

Heya,

in the scope of semantic interoperability it is not unusual to structure 
named types in taxonomies (a fancy word for basically categories of 
categories, etc). Maybe taxonomical tagging (associating with category) 
of various similar (e.g., "temperature"'esque) data model items renders 
the model close enough to an information model - and therefore 
remediates this... creative use?

But maybe the complexity of types and units is too big for such a 
simplistic approach?

Viele Grüße,

Henk

---

From: Milan Milenkovic <[email-masked]>
Date: Mon, 31 Aug 2020 15:22:35 +0000

Hi Karsten, Wouter et al.

For your example, I was going to suggest the range fraction or % solution but Wouter beat me to it.

More importantly, I think we should be pragmatic and aim for the 80% solution (which, according to the Pareto principle, may require definition of only 20% of use cases ;-).  IMO, luminosity ad brightness are examples of a relatively skewed minor use case in a specific domain that is consuming disproportionate amounts of time and effort to address and that complicates many a solution for what is at best a small benefit.  Such things can be tabled, and possibly revisited later, to allow progress on solutions for the most common use cases.

Regards,
Milan Milenkovic, Principal
IoTsense LLC, www.iotsense.com, +1 650 431-8280

-----Original Message-----
From: One Data Model Group <[email-masked]> On Behalf Of Wouter van der Beek (wovander)
Sent: Monday, August 31, 2020 7:51 AM
To: Carsten Bormann <[email-masked]>; [email-masked]
Cc: One Data Model Group <[email-masked]>; [email-masked]
Subject: RE: [One Data Model Group] [Asdf] Representation issues and protocol bindings

Hi Carsten,

I think using JSON as a notation actually helps, It avoids using the more precise thus more prescriptive  int32/64/... data types.
e.g. just Boolean, number and integer as base.

Kind Regards,
Wouter

-----Original Message-----
From: ASDF <[email-masked]> On Behalf Of Carsten Bormann
Sent: Monday, August 31, 2020 3:26 PM
To: [email-masked]
Cc: One Data Model Group <[email-masked]>; [email-masked]
Subject: [Asdf] Representation issues and protocol bindings

Grüße, Carsten

---

From: Alexander Pelov <[email-masked]>
Date: Mon, 31 Aug 2020 17:58:47 +0200

Hi Carsten, all,

These are indeed some interesting questions, and I am not sure to
what extent they can be solved in a generic way.

In our work on adding parsing capabilities to YANG files (see
https://tools.ietf.org/html/draft-petrov-t2trg-youpi-01 ) we've done some
of the things you mentioned. For example, in YANG you have the built-in
capability to describe the range of a value, e.g. if it goes from 0-100, or
from 1-255. That of course would solve the first part of your question.

I think that solving the full problem may be a little bit more delicate.
For example, someone just might choose 0-1000, where 0 is max brightness,
which then goes to min brightness at around 950 and then again to maximum
brightness at 1000. Why would anyone do something like this? I think the
question would be mostly - if someone does it, how to handle it graciously.
There may be something like a mapping, two-way function, that first
transforms the crazy thing into a linear graduation, which can then be
handled in a more "understandable" way.

So probably, a combination of the two:
1) having the hypothesis that a variable is "linear", with known MIN/MAX
2) annotating the MIN/MAX values (e.g. 0=off, 255=bright)
2.1) optionally annotation intermediate values (e.g. 10=very dim)
3) having an (optional) transformation function to/from the linear function
used by ASDF (in case the variable is not linear)

Cheers,
Alexander

On Mon, Aug 31, 2020 at 5:22 PM Milan Milenkovic <[email-masked]> wrote:

> More importantly, I think we should be pragmatic and aim for the 80%
> solution (which, according to the Pareto principle, may require definition
> of only 20% of use cases ;-).  IMO, luminosity ad brightness are examples
> of a relatively skewed minor use case in a specific domain that is
> consuming disproportionate amounts of time and effort to address and that
> complicates many a solution for what is at best a small benefit.  Such
> things can be tabled, and possibly revisited later, to allow progress on
> solutions for the most common use cases.
>
> Regards,
> I think using JSON as a notation actually helps, It avoids using the more
> precise thus more prescriptive  int32/64/... data types.
> Enum values I hope everyone will start using string value as enum value,
> where the string can have an actual meaning, e.g.
> As example I think brightness should be expressed as % in number so that
> one can choose its precision on the wire.
> So if one encounters the brightness on system A one should know the actual
> data on the wire so that one can map it to the oneDM model in SDF. If one
> needs to use it on system B, one needs to know how to write the data on the
> wire for System B.
> But I think we all experienced that over time resolutions go up, good
> example of this is RGB,  0-255- 8 bits, then 16 bits, 24 bits ...
>
> In today’s OneDM call, Bruce Nordman brought up the issue that, in the
> end, we’ll need concrete representations to talk to devices and use their
> data.
>
> So if we have one ecosystem that uses 0..100 for describing the brightness
> setting for a lamp, another one that uses 0..254 (where 255 means something
> complete different), and a third with 0..65535, what do we do?  (And these
> might also differ whether they describe a emitted light power level or a
> perceptive luminous flux level.)
>
> The underlying problem is that we are abusing data model level description
> techniques (in part borrowed from json-schema.org) to describe
> information models.
> That works reasonably well until we start taking these data model level
> descriptions at face value.  The fact that some converged model uses a
> scale based on the L component of Lu’v’ does not mean that everybody has to
> represent their ecosystem model the same way.
>
> The obvious second problem is that we haven’t tackled a framework for
> describing protocol bindings (which, initially, will mostly be ecosystem
> bindings).  That would be the place where we say how the L component needs
> to mapped to the ecosystem specific concrete representation.  Since that
> mapping, in principle, can have arbitrary complexity, completely covering
> all cases requires Turing-equivalent functionality in a description
> language.  Or we could go for an 80 % solution and then, for the 20 %,
> register mapping components that are more complex in an IANA registry.
>
> Let’s discuss this based on some real-world examples — it is easy to
> construct artificial ones that have more complexity than we actually need.
>
> CCing T2TRG as well because quite a few people there are familiar with the
> problem; maybe we want to have the bulk of the discussion on [email-masked]
> though.
>
> Grüße, Carsten
>
> --
> ASDF mailing list
> [email-masked]

---

From: David Kemp <[email-masked]>
Date: Mon, 31 Aug 2020 12:31:01 -0400

For the 80% case (e.g. temperature), a non-solution is to use an attribute
called "temperature".  Every device that deals with temperature must
understand standard units of temperature, which should be communicated
using attribute names like "kelvins", "degrees_f", or "degrees_c".  The
data format could (should?) be standardized as float, which doesn't make a
difference in JSON but does in CBOR.  What if you want to design a device
that uses int8 between 0 and 100 to represent -40C to 200C?  Then you're
not in the 80% any more.

The other 20% should be addressed using the same principle: "brightness" is
a useless property name, "lumens" is better in that it specifies a
measurable value, but has the disadvantage that it is absolute, not
relative to the capacity of the device.  A relative attribute would at
least need to specify the gamma of the control function.

Time could be defined similarly, specifying units (e.g., nanoseconds,
milliseconds, seconds) of resolution for intervals and an epoch for
date-times.  Or for the simple 80% a cumbersome but generally-understood
RFC 3339 string could be used, hopefully using an "rfc3339-date-time"
attribute, not "date-time".

The general principle is that standard units need to be defined in the
first place, and then attribute names should refer to the standard, not a
unitless name of a feature.

Dave

---

From: Milan Milenkovic <[email-masked]>
Date: Mon, 31 Aug 2020 19:03:04 +0000

This brings up another point in determining standards strategy - who should bear the burden of supporting uncommon representations like your temperature example? It is either its creator (by adding a few lines of code to bring it to “80%”) or everybody else by having to implement a more complicated accommodating  standard?

I think simpler specifications that cover common cases are a better way to go.

Sent from Milan's phone.

On Aug 31, 2020, at 18:31, One Data Model Group <[email-masked]> wrote:

For the 80% case (e.g. temperature), a non-solution is to use an attribute called "temperature".  Every device that deals with temperature must understand standard units of temperature, which should be communicated using attribute names like "kelvins", "degrees_f", or "degrees_c".  The data format could (should?) be standardized as float, which doesn't make a difference in JSON but does in CBOR.  What if you want to design a device that uses int8 between 0 and 100 to represent -40C to 200C?  Then you're not in the 80% any more.

The other 20% should be addressed using the same principle: "brightness" is a useless property name, "lumens" is better in that it specifies a measurable value, but has the disadvantage that it is absolute, not relative to the capacity of the device.  A relative attribute would at least need to specify the gamma of the control function.

Time could be defined similarly, specifying units (e.g., nanoseconds, milliseconds, seconds) of resolution for intervals and an epoch for date-times.  Or for the simple 80% a cumbersome but generally-understood RFC 3339 string could be used, hopefully using an "rfc3339-date-time" attribute, not "date-time".

The general principle is that standard units need to be defined in the first place, and then attribute names should refer to the standard, not a unitless name of a feature.

Dave

On Mon, Aug 31, 2020 at 11:22 AM Milan Milenkovic <[email-masked]<mailto:[email-masked]>> wrote:
For your example, I was going to suggest the range fraction or % solution but Wouter beat me to it.

-----Original Message-----
From: One Data Model Group [email-masked]> On Behalf Of Carsten Bormann

The underlying problem is that we are abusing data model level description techniques (in part borrowed from json-schema.org<http://json-schema.org>) to describe information models.
That works reasonably well until we start taking these data model level descriptions at face value.  The fact that some converged model uses a scale based on the L component of Lu’v’ does not mean that everybody has to represent their ecosystem model the same way.

---

From: Bruce Nordman <[email-masked]>
Date: Mon, 31 Aug 2020 13:18:43 -0700

I'm glad this topic has come up. I realize the work to date on SDF and such
is an absolutely essential foundation to interoperability, but that other
standardization is also needed. In the lighting case, Carsten noted
originally that it can be specified with respect to emitted light or
human-perceived light (we are non-linear), it could also be to light
delivered to a surface or to input electrical power - and any of these
could be absolute or relative to the maximum a source can provide.  Another
example is enumerated named light colors that can be spoken to smart
speaker systems (e.g. Amazon or Google); these are similar but not the
same, may not map to the same actual color, and colors are culturally
varying in addition to varying with language.

I had assumed from the start that ODM would define a reference semantic
model that any protocol could be translated into, or out of, which
necessarily requires picking some existing model to use directly or to
adapt, or creating a new one.  From the ODM call today I take it that this
is a topic which ODM has not yet settled on an approach to.

While standardizing on things like the naming and meaning of individual
element is needed, in some cases information is represented in ways which
is just different.  I have worked for many years on the concept of 'power
state' (and aided in our move from a 2 power state world - on/off - to one
with 3 - on/sleep/off). In some cases, models combine power state with a
functional state of device (e.g. if a printer/MFD is printing, scanning,
neither, etc.) into one enumeration.

I am not sure of the right name for this topic area -- "semantics" seems to
cover a lot more than this -- and I will defer to the rest of you as to
when it should be taken up.  That said, I think it needs to be on the
agenda somehow.  I do think that IANA could play a useful role in hosting
some standard content for this - certainly enumerations but also other
content - when no quality existing content exists to point to and there
isn't a good option for another org. to take it up.  An example topic that
I think could be usefully standardized through IANA is Device
Classification:
   *Device Classification*. Report on Simple Universal Device Classification
<https://drive.google.com/open?id=0B8B9XW6B7prlc0pfWDNnUlU5dmc>
(2014), Internet
Draft <http://tools.ietf.org/html/draft-nordman-classification-00> and
Presentation <http://tools.ietf.org/agenda/82/slides/appsawg-8.pdf> from
IETF 82. *Taxonomy*
<https://drive.google.com/open?id=0B8B9XW6B7prlU0tWdVhENDE3ODg> of
electronic and miscellaneous products (2006)

I do agree with the sentiment that complexity is an enemy here and that
some sort of 80/20 principle should apply.  I think that ASCII and UniCode
show how one can have a basic functionality alongside a much more
sophisticated one and make good use of both.  We need to create ASCII first.

Thanks,
--Bruce

On Mon, Aug 31, 2020 at 12:17 PM Milan Milenkovic <[email-masked]>
wrote:

> This brings up another point in determining standards strategy - who
> should bear the burden of supporting uncommon representations like your
> temperature example? It is either its creator (by adding a few lines of
> code to bring it to “80%”) or everybody else by having to implement a more
> complicated accommodating  standard?
>
> The other 20% should be addressed using the same principle: "brightness"
> is a useless property name, "lumens" is better in that it specifies a
>> So if we have one ecosystem that uses 0..100 for describing the
>> brightness setting for a lamp, another one that uses 0..254 (where 255
>> means something complete different), and a third with 0..65535, what do we
>> do?  (And these might also differ whether they describe a emitted light
>> power level or a perceptive luminous flux level.)
>>
>> The underlying problem is that we are abusing data model level
>> description techniques (in part borrowed from json-schema.org) to
>> describe information models.

-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
*nordman.lbl.gov <http://nordman.lbl.gov>*
[email-masked]
510-486-7089; m: 510-501-7943
m: 510-501-7943

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 31 Aug 2020 22:18:55 +0200

I think it is already relatively easy to find the right level of abstraction for information that can be expressed in SI units.  
(Units can be specified in SDF 1.0.)

SenML (RFC 8428) got that right, so I think we can follow that example in SDF.
We did have to make a little bit of a compromise (adding scaling prefixes in RFC 8798) in areas where the natural units are habitually scaled (there aren’t many electricity meters indicating J — it’s always kWh), but even here it should be easy to agree on a natural unit between domain experts.

But the problem remains how the ecosystem specifications can relate to the converged model if that had to abstract some more.  And that’s where the binding comes in.  To make ecosystem experts feel at home, we probably need to make this rather accessible.

For information that is a ratio to a reference value (e.g., a lamp an undefined metric of which can be set to a value between 0 to 100 %), SenML has “/”  (the dimensionless unit).  So we would normally not use percentages (or permille, or ppm, …), but a number that is typically clamped between 0 and 1.  Of course, most ecosystems will scale this to get an integer representation, and that is probably the largest source of variation (*).

Also, RFC 8798 is limited to linear scales (scale/offset).  For sound and RF power levels we can cheat with dB.  For lighting, the models are more complicated (which led to gamma and all that).  If different ecosystems use different models here, there may be no straightforward way to do the conversions.  So we have to be prepared to express these anyway.

Grüße, Carsten

(*) And that when it should have been plainly obvious that all IoT devices should express temperatures as an integer value in centikelvin (cK), so a 16-bit unsigned value from 0 to 65535 can express most real-life sensor values (between absolute zero and 382.2 °C), and simply subtracting 27315 and dividing by 100 gives you the value in °C :-)

---

From: Michael Richardson <[email-masked]>
Date: Mon, 31 Aug 2020 16:47:15 -0400

Carsten Bormann <[email-masked]> wrote:
    > But the problem remains how the ecosystem specifications can relate to
    > the converged model if that had to abstract some more.  And that’s
    > where the binding comes in.  To make ecosystem experts feel at home, we
    > probably need to make this rather accessible.

    > For information that is a ratio to a reference value (e.g., a lamp an
    > undefined metric of which can be set to a value between 0 to 100 %),
    > SenML has “/”  (the dimensionless unit).  So we would normally not use
    > percentages (or permille, or ppm, …), but a number that is typically
    > clamped between 0 and 1.  Of course, most ecosystems will scale this to
    > get an integer representation, and that is probably the largest source
    > of variation (*).

So for a lamp, the alternative to "/" is that the brightness be specified in
lumens (or maybe candela in some cases).

    > (*) And that when it should have been plainly obvious that all IoT
    > devices should express temperatures as an integer value in centikelvin
    > (cK), so a 16-bit unsigned value from 0 to 65535 can express most
    > real-life sensor values (between absolute zero and 382.2 °C), and
    > simply subtracting 27315 and dividing by 100 gives you the value in °C
    > :-)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 1 Sep 2020 01:23:08 +0200

On 2020-09-01, at 01:16, Clarke Stevens <[email-masked]> wrote:
> 
> 		• NOTE: Currently, the code to map between models is pseudo code represented as a comment rather than actual executable code in a specific language. This choice was made to remain independent of any programming language.

Right.  My hope was that maybe we can find an 80 % solution here that is machine-processable, and leave the other 20 % to some registered features.  Converting between one of the RGBs and CMYK is probably going to land in the 20 %.

Grüße, Carsten

---

From: Clarke Stevens <[email-masked]>
Date: Mon, 31 Aug 2020 23:16:55 +0000

I suggest we consider the approach used by OCF.

Here is the essence.

  *   As Bruce suggests, OCF chooses a minimal canonical model.
  *   OCF hosts models from other organizations on the same data platform as the canonical models (ODM already does this).
  *   OCF hosts mapping rules between the two models (called “derived models" in OCF)
  *   All of these models are machine readable
  *   Methods are defined for both directions of mapping (other_org -> OCF and OCF -> other_org)
  *   Mappings are not required to be 1 to 1. For example you can map from RGB color to CMYK color in both directions (supports intermediate calculation values and complex formulas)
     *   NOTE: Currently, the code to map between models is pseudo code represented as a comment rather than actual executable code in a specific language. This choice was made to remain independent of any programming language.

This allows OCF to define a “north star” canonical data model while allowing other organizations to map whatever they have to this canonical model in both directions. If other organizations choose to migrate to the “north star,” they can can do it at their own pace and on their own terms. Conceivably, ODM could support evolving models and several versions from other organizations. ODM could also go beyond what OCF did and actually choose an implementation language and completely automate the mapping.

Thanks,
-Clarke

On Aug 31, 2020, at 2:18 PM, Bruce Nordman <[email-masked]<mailto:[email-masked]>> wrote:

  CAUTION: This email is from an external source. Do not click links or open attachments unless you recognize the sender and know the content is safe.

I'm glad this topic has come up. I realize the work to date on SDF and such is an absolutely essential foundation to interoperability, but that other standardization is also needed. In the lighting case, Carsten noted originally that it can be specified with respect to emitted light or human-perceived light (we are non-linear), it could also be to light delivered to a surface or to input electrical power - and any of these could be absolute or relative to the maximum a source can provide.  Another example is enumerated named light colors that can be spoken to smart speaker systems (e.g. Amazon or Google); these are similar but not the same, may not map to the same actual color, and colors are culturally varying in addition to varying with language.

I had assumed from the start that ODM would define a reference semantic model that any protocol could be translated into, or out of, which necessarily requires picking some existing model to use directly or to adapt, or creating a new one.  From the ODM call today I take it that this is a topic which ODM has not yet settled on an approach to.

While standardizing on things like the naming and meaning of individual element is needed, in some cases information is represented in ways which is just different.  I have worked for many years on the concept of 'power state' (and aided in our move from a 2 power state world - on/off - to one with 3 - on/sleep/off). In some cases, models combine power state with a functional state of device (e.g. if a printer/MFD is printing, scanning, neither, etc.) into one enumeration.

I am not sure of the right name for this topic area -- "semantics" seems to cover a lot more than this -- and I will defer to the rest of you as to when it should be taken up.  That said, I think it needs to be on the agenda somehow.  I do think that IANA could play a useful role in hosting some standard content for this - certainly enumerations but also other content - when no quality existing content exists to point to and there isn't a good option for another org. to take it up.  An example topic that I think could be usefully standardized through IANA is Device Classification:
   Device Classification. Report on Simple Universal Device Classification<https://drive.google.com/open?id=0B8B9XW6B7prlc0pfWDNnUlU5dmc> (2014), Internet Draft<http://tools.ietf.org/html/draft-nordman-classification-00> and Presentation<http://tools.ietf.org/agenda/82/slides/appsawg-8.pdf> from IETF 82. Taxonomy<https://drive.google.com/open?id=0B8B9XW6B7prlU0tWdVhENDE3ODg> of electronic and miscellaneous products (2006)

I do agree with the sentiment that complexity is an enemy here and that some sort of 80/20 principle should apply.  I think that ASCII and UniCode show how one can have a basic functionality alongside a much more sophisticated one and make good use of both.  We need to create ASCII first.

Thanks,
--Bruce

On Mon, Aug 31, 2020 at 12:17 PM Milan Milenkovic <[email-masked]<mailto:[email-masked]>> wrote:
This brings up another point in determining standards strategy - who should bear the burden of supporting uncommon representations like your temperature example? It is either its creator (by adding a few lines of code to bring it to “80%”) or everybody else by having to implement a more complicated accommodating  standard?

Sent from Milan's phone.

On Aug 31, 2020, at 18:31, One Data Model Group <[email-masked]<mailto:[email-masked]>> wrote:

Dave

-----Original Message-----
From: Bruce Nordman arget="_blank">[email-masked]<mailto:[email-masked]>> On Behalf Of Carsten Bormann

The underlying problem is that we are abusing data model level description techniques (in part borrowed from json-schema.org<http://json-schema.org/>) to describe information models.
That works reasonably well until we start taking these data model level descriptions at face value.  The fact that some converged model uses a scale based on the L component of Lu’v’ does not mean that everybody has to represent their ecosystem model the same way.

--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov<http://nordman.lbl.gov/>
[email-masked]<mailto:[email-masked]>
510-486-7089; m: 510-501-7943
m: 510-501-7943