QUDT, schema.org, IoT/WoT etc

[Dan Brickley]

Hi Ralph, (cc public schema.org iot sync email list)

In the schema.org community we are talking again(*) about how best to
integrate QUDT with our existing quantitative measure -related
terminology. This is particularly driven by discusions around Internet
of Things, and related interest in the W3C Web of Things group. We are
particularly interested in finding markup designs (e.g. in JSON-LD)
that can be simple enough for mainstream developer / publisher usage,
but yet sensibly grounded in QUDT.

My understanding is that that you are in the process of updating to
version 2.0. Is there anything you can share with us about that
transition? Should we wait, or get started with what is currently
available?

Thanks for any pointers,

cheers,

Dan


(*) https://github.com/schemaorg/schemaorg/issues/1390#issuecomment-285270847

[Jason Koh]

Hi Ralph (and Jack/Steve!),

One of the big interests is to find common vocabularies between schema.org and QUDT to adopt directly, which is a lazy first step. Some of the QUDT vocabularies common in schema.org are not public, so it would be great to have an access to the git repository so that I can find the commonality first. 

With regards,

Jason Koh

cseweb.ucsd.edu/~jbkoh

On Sat, Mar 11, 2017 at 8:09 AM, Ralph TQ [Gmail] <rhod...@topquadrant.com> wrote:

Hi Dan

Quick response for now.

Have you seen the latest at www.qudt.org? Some ontologies are there now and there is ucum code support. 

One possibility is to have access to QUDT Git REPO. Is that of interest?

More later.

Regards,

Ralph

rhod...@topquadrant.com

[Jason Koh]

Dear Ralph, 

Thanks for sharing the repository. I will share some thoughts once I get some connections between QUDT and schema.org.

With regards,

Jason Koh

cseweb.ucsd.edu/~jbkoh

On Sun, Mar 19, 2017 at 3:23 PM, Ralph TQ [Gmail] <rhod...@topquadrant.com> wrote:

Jason,

We have moved forward on publishing a number of graphs, This week we should make more progress.

Your GitHub ID jbkoh (https://github.com/jbkoh) now has read-only access to QUDT r2.0

Regards, Ralph

[Jason Koh]

Original post: https://github.com/schemaorg/schemaorg/issues/1390#issuecomment-289359120

I have looked at both schema.org Quantity/QuantitativeValue and qudt.org's Quantity. Here, I will use qudt: and schema: for each namespace.

## schema.org

First of all, as @rvguha pointed out, it is obvious that we need to unify schema:QuantitativeValue and schema:Quantity in schema.org. Here I only consider schema:Quantity for simplicity. (I personally think that there would be no problem substitute QuantitativeValue with Quantity, which is just removing QuantitativeValue)

Examples of schema:Quantity in RDFa and JSON-LD

(source:http://linter.structured-data.org/examples/schema.org/VisualArtwork/)

```

RDFa

<span property="height" typeof="Distance">180 cm</span>

JSON-LD

"height": [

        {

          "@type": "Distance",

          "name": "180 cm"

        }

      ],

```

(source:http://schema.org/duration)

```

RDFa

<meta property="duration" content="T1M33S" />

JSON-LD

 "duration": "T1M33S",

```

A few problems with the current design

- There are various ways of implementations. (meta vs span depending on the purpose)

- Values are encoded in names often without rules.

  - Value type is not forced.

- An author should encode units in the value.

## QUDT

```

Turtle

example:person1 qudt:hasQuantity example:height1 . # or example:person1 example:hasHeight example:height1

example:Height rdfs:subClassOf qudt:Quantity; # example:Height should be defined as a Quantity.

example:height1 a example:Height;

                qudt:quantityValue qudt:height_value1 .

example:height_value1 a qudt:QuantityValue;

                      qudt:unit unit:CM;

                      qudt:numericValue "180"^^dtype:numericUnion .

```

## Suggestions and discussions

1. Can we remove schema:QuantitativeValue? (use schema:Quantity instead)

2. If subproperty is meaningful in schema.org, I'd suggest make all quantity-related properties under qudt:hasQuantity.

3. Then, all quantities such as schema:Energy and schema:Distance will be under schema:Quantity (which would be same as qudt:Quantity).

4. All schema:Quantity can have qudt:unit and qudt:numericValue as properties.

5. If the above are all agreeable, mapping vocabularies between schema.org and QUDT must be straigtforward.

With regards,

Jason Koh

cseweb.ucsd.edu/~jbkoh

[Dan Brickley]

On Mar 27, 2017 15:06, "Jack Hodges" <jhodg...@gmail.com> wrote:

I prefer Simon's first example. Regarding the schema.org example, it doesn't seem very semantic to lump values and units together because you then have the same value for every possible unit. Also, they must then have some software that parses the value from the unit instead of having the semantics clearly defined in the model. Sloppy. Is this model complying with any quantity/unit standards? What is its provenance? Is the interest in matching up QUDT to [whatever] simply the fact that [whatever] exists and not the quality of [whatever], because I have a hard time putting cycles into that kind of effort.

The interest comes from wanting to improve schema.org's approach by grounding it in QUDT, in particular as we explore IoT-related schemas where measures and sensors are a common concern.

The structured text approach used in parts of schema.org dates from 2011 when nobody knew if it would succeed. The design bias then was strongly for publisher/webmaster simplicity even if it made work for consumers. While this was successful and schema.org is used on million of sites, there is scope (as you note) to tighten things up. Hope that helps clarify the backstory and motivations.

Dan

Jack

Sent from my iPad

On Mar 27, 2017, at 12:17 AM, <Simo...@csiro.au> <Simo...@csiro.au> wrote:

Jason –

 

You are not using the ‘QuantityKind’ apparatus.

This is where the semantics (and dimensionality) of a Quantity are usually provided.

Re-writing your example below to leverage this might be done in a couple of ways, both using a qudt:QuantityKind to provide the semantics of ‘Height’:

 

## QUDT – Option 1 – no subclass

```

Turtle

example:person1 qudt:hasQuantity example:height1 .

 

example:HeightKind a qudt:QuantityKind ;

  qudt:applicableSIUnit unit:M ;

  qudt:generalization quantitykind:Length ;

  qudt:hasDimension qudt:DIM_SI-m ;

  rdfs:label "Height" ;

.

 

example:height1 a qudt:Quantity;

            qudt:quantityValue qudt:height_value1 ;

qudt:quantiyKind example:HeightKind .

 

example:height_value1 a qudt:QuantityValue;

                      qudt:unit unit:CM;

                      qudt:numericValue "180"^^dtype:numericUnion .

 

```

 

## QUDT – Option 2 – using a subclass

```

Turtle

# as above plus this sub-class definition

 

example:HeightQuantity

  rdfs:subClassOf qudt:Quantity ;

  rdfs:subClassOf [

      rdf:type owl:Restriction ;

      owl:hasValue example:HeightKind ;

      owl:onProperty qudt:hasQuantityKind ;

    ] ;

.

 

example:height1 a qudt:Quantity , example:HeightQuantity ;

            qudt:quantityValue qudt:height_value1 .

 

```

 

 

Simon

[Jason Koh]

Finding a sweet spot between usability and expressivity is always difficult. I add my findings here. Any comments are welcome.

## Vocabulary-wise:

I see several one-to-one mapping between qudt:QuantityKind and schema:Quantity such as

schema:Mass <-> qudt:Mass

schema:Energy <-> qudt:EnergyAndWork (side note: I would argue to keep Energy other than using EnergyAndWork to avoid confusions for users.)

schema:Duration <-> qudt:? (What should this be? Time?)

schema:Distance <-> qudt:Length (will this make sense?)

The first task would be curating necessary vocabularies from QUDT vocabularies. It's very comprehensive. I don't mind adopting the entire vocabularies once QUDT's internal review process is done, but I will leave it to the schema.org's curation policy. However, I suspect how much MolarEnergy will be used for any domains that schema.org targets for example. I will do some this weekend.

To QUDT developers: do you have any metrics for how many each of vocabularies is being used in public?

## Structure-wise:

Another dimension of decision that we should make is the quantity structure. If we follow QUDT's structure, a user (webmaster) should provide the quantity's QuantityKind and Unit. Let me try to give an example in JSON-LD. My experience with JSON-LD is not matured, so please correct me if needed.

```

# Differentiate namespaces to make vocabularies' origins clear for now.

# All these could be integrated into schema.org.

{

  "@context": {

    "schemaorg": "https://schema.org/",

    "qudt": "http://qudt.org/schemas/qudt/",

    "unit": "http://qudt.org/vocab/unit/",

    "quantitykind": "http://qudt.org/vocab/quantitykind/",

    "xs": "http://www.w3.org/2001/XMLSchema"

 },

"name": "Jason Koh",

"@type": "Person",

"schemaorg:height": {

    "@type": "qudt:Quantity",

    "qudt:quantityKind": "quantitykind:HeightKind",

    "qudt:quantityValue": {

      "@type": "qudt:QuantityValue",

      "qudt:numericValue": 182, # This could be {"@type": "xs:float", "@value": 182}, but simplified for now.

      "qudt:unit": "qudt:CM"

    }

  }

}

```

Currently, there is an indirection to get the actual value. "height"->"quantityValue"->"numericValue"

Why are qudt:Quantity and qudt:QuantityValue separated? Is it for representing a same value with different units? I personally wonder if webmasters would be capable enough to understand these to use. I'd argue to use numeric values to qudt:Quantity directly. Any thoughts from QUDT and iot.schema.org committee?

If we remove that indirection, it would look like:

```

{

  "@context": {

    "schemaorg": "https://schema.org/",

    "qudt": "http://qudt.org/schemas/qudt/",

    "unit": "http://qudt.org/vocab/unit/",

    "quantitykind": "http://qudt.org/vocab/quantitykind/",

    "xs": "http://www.w3.org/2001/XMLSchema"

 },

"name": "Jason Koh",

"@type": "Person",

"schemaorg:height": {

    "@type": "qudt:Quantity",

    "qudt:quantityKind": "quantitykind:HeightKind",

    "qudt:numericValue": 182,

    "qudt:unit": "qudt:CM"

    }

  }

}

```

I think this is simpler than before and requires users to put decent amount of semantics, which are unit, value and QuantityKind.

In either way, the change to schema.org would be (which I think is fair)

1. following should be created:

  (1) schemaorg:quantityKind or hasQuantityKind

  (2) schema:QuantityKind

  (3) schemaorg:numericValue

  (4) schemaorg:unit or hasUnit

  (5) schemaorg:Unit (superclass of all units)

  (6) schemaorg:quantityValue (if we follow qudt directly.)

  (7) schemaorg:QuantityValue 

2. schema.org:Quantity should have more properties as following.

  (1) schemaorg:numericValue

  (2) shcmeaorg:quantityKind

  (3) schemaorg:unit

  (4) schemaorg:quantityValue (if we follow qudt directly.)

I would like to listen to both QUDT and schema.org committee for this issue. 

Thank you all

(attach github link for Markdown visualization: https://github.com/schemaorg/schemaorg/issues/1390#issuecomment-289359120)

With regards,

Jason Koh

cseweb.ucsd.edu/~jbkoh

[Jason Koh]

It would be great for someone to try RDFa encoding of the example as it is schema.org's canonical representation.

With regards,

Jason Koh

cseweb.ucsd.edu/~jbkoh

[Dan Brickley]

On 31 March 2017 at 22:36, Jason Koh <jb...@eng.ucsd.edu> wrote:
> It would be great for someone to try RDFa encoding of the example as it is
> schema.org's canonical representation.

Actually RDFa is somewhat overshadowed by Microdata (it's nearly
identical for publishers, but harder for parser writers). And recently
there seems to be a rough consensus to move towards JSON-LD in many
settings. We do use RDFa for our on-disk representation of the actual
schema.org schemas though, which is perhaps how we give the impression
it is canonical...

Thanks for the investigations - I'll try to find time this week to
digest the various suggestions. I had set myself the task of reading
https://www.amazon.co.uk/Dimensional-Analysis-Percy-Williams-Bridgman/dp/1297838467
first, which in retrospect may have been too ambitious for a week with
a lot of travel in it ;)

cheers,

Dan

[Jason Koh]

Hi Steve,

I asked about separation between Quantity anf QuantityValue. If there is not enough use cases of separating them out, getting Quantity to have numeric Value directly looks simpler to me.

On Apr 1, 2017 9:34 AM, "Steve Ray" <steveray...@gmail.com> wrote:

Jason,

You asked about the separation between qudt's notion of Quantity and QuantityKind. Your example confuses those concepts a bit.

Quantity is used to capture the context of the measurement, such as a person's height. The QuantityKind identifies the dimension, which in your example would be length (not a person's height, which is contextual).

Steven R. Ray, Ph.D.
Email:    st...@steveray.com
Phone: (650) 587-3780 (CA)
              (202) 362-5059 (DC)
Cell:      (202) 316-6481

[Jason Koh]

Yes, that's correct. Unit can come down to a property of Quantity as well.

On Apr 1, 2017 9:52 AM, "Steve Ray" <steveray...@gmail.com> wrote:

Jason,

My mistake, I had mis-remembered your question.

Regarding Quantity and QuantityValue, I understand your point, but of course they really are distinct concepts. You are really just asking about the practicality of making QuantityValue a property of Quantity, rather than an object in its own right, correct?

Steven R. Ray, Ph.D.
Email:    st...@steveray.com
Phone: (650) 587-3780 (CA)
              (202) 362-5059 (DC)
Cell:      (202) 316-6481

[Dan Brickley]

On 1 April 2017 at 19:00, Jason Koh <jb...@eng.ucsd.edu> wrote:
> Yes, that's correct. Unit can come down to a property of Quantity as well.
>
> On Apr 1, 2017 9:52 AM, "Steve Ray" <steveray...@gmail.com> wrote:
>>
>> Jason,
>> My mistake, I had mis-remembered your question.
>> Regarding Quantity and QuantityValue, I understand your point, but of

May I suggest we try to keep the namespace prefixes e.g. schema:,
qudt: etc attached to such term names, for purposes of intelligibility
of these discussions?

Schema.org has schema:Quantity, schema:QuantitativeValue; QUDT has
QuantityValue ... it is pretty hard to hold all these similar names in
my head (and I even work on schema.org every day), not to mention
similarities between property and related type names...

cheers,

Dan

[Dave Raggett]

Hi Ralph,

First of all thanks for giving me access to the QUDT GitHub repository. I don’t have any time to look at it in detail right now, but thought it would be helpful to briefly describe the perspectives from work at W3C on the Web of Things and to arrange for a call to discuss opportunities for collaboration.

There is general agreement that the Internet of things is fragmented, and that this is increasing the costs and risks for all concerned, and holding back the market potential. We can seek inspiration from past experiences. The Internet is an abstraction layer that enablers developers to create end to end services across a heterogeneous collection of networks and networking technology. This has enabled a vast market in hardware and services. W3C and the IETF have likewise been very successful in establishing the Web as a vendor independent open platform for distributed services, building on top of the Internet with open standards for HTML and HTTP. We now want to duplicate this success through open standards for an abstraction layer that reduces the effort for creating services over a heterogeneous collection of IoT standards suites, communication patterns, protocols and data formats.

The essential idea is to use Linked Data as a lingua franca for describing things whether they are physical or abstract entities. Things can be exposed to applications as objects with properties, actions, events and metadata. The means to express units of measure is a common requirement when it comes to describing the data collected from sensors or used to control actuators. Many developers will be mostly interested in the object model by which things are exposed to applications. The object model can be represented simply in JSON without the need to understand the underlying mapping to Linked Data. My study of IoT standards suites such as OCF, oneM2M and ECHOnet makes it clear that there is a need to be able to use a single name for the combination of the unit of measure and the scale factor, e.g. “milliamps" which is the current in amperes multiplied by a scale factor of one thousand. 

For use in JSON we would like to be able to support standard abbreviations e.g. “mA” or the longer form “milliamps”.  The mapping from this to an RDF concept can be given in a context file that binds names to URIs.  In some cases the same abbreviation is used differently in different domains. This can be handled via the corresponding context files.

Another group of developers will be interested in supporting semantic based search and composition of services. These developers are comfortable with the tools and technologies for Linked Data. The thing descriptions link to a semantic model of units of measure, see the attached figure for an example. The “td” prefix is for illustration purposes and refers to a putative "thing description" namespace. The tools for composing services will be able to exploit the  semantic models to verify semantic interoperability and to determine what kinds of transformations are needed, e.g. when communicating parties are using different scale factors, or different units, e.g. units of pressure as pascals, pounds per square inch or bar.

The W3C Web of Thing Working Group has a scope that is limited to developing a cross domain vocabulary for thing descriptions and as such we are looking to other groups to work on domain specific vocabularies. QUDT is interesting as a rich ontology for units of measure, and I would like to explore the role for standards for RDF concepts for a combination of units and scale factors (td:milliamps in the figure) and for the associated abbreviations and full names for use in lightweight models of things using JSON and HTML.

Would it make sense to arrange a phone call to chat further?

Best regards,

Dave Raggett <d...@w3.org> http://www.w3.org/People/Raggett

W3C lead for the Web of things

[Dave Raggett]

Hi Jack,

I am seeking standards that apply to the object model for things and which link to richer semantic models for services that deal with discovery, composition and validation of services.  As I pointed out in my email, we need standards for the abbreviations and full names of units of measure with their scale factor, along with the corresponding RDF nodes. These nodes can then link to the richer ontology that QUDT for example provides. I want to initiate a dialogue to share perspectives and build a common understanding, and we can then figure out what needs to be done where.

An analysis of use cases and IoT standards suites confirms the appropriateness of properties, actions and events for the object model exposed for things to applications. The W3C Web of Things Working Group is also defining a corresponding API. The semantic descriptions are linked from the object model, e.g. using ref:type to indicate that a thing is an instance of some semantic class.  The W3C Web of Things Interest Group has launched a Linked Data and Semantic Processing Task Force to drive the work on semantic interoperability, including discovery, composition and validation of services. 

A phone conversation would seem to be a good starting point for reaching a common understanding.

On 2 Apr 2017, at 07:28, Jack Hodges <jhodg...@gmail.com> wrote:

Dave,

I do not think that we know each other. I am reading your note to Ralph and wondering what the question is that you would like answered. QUDT has a rigorous Unit model that does what you are looking for. At the same time, I am curious about the TD model because, having looked at the documentation and the ontology, I do not see any content (as in a structured information model) in it at all. I have no personal issue with breaking up the world into Actions, Events, Properties, and Things for the purposes of servients conveying information to and for humans, human-interpreted content, or human-written code that will impart meaning to those descriptions. But if these terms are to have meaning, they must have dependencies on each other that make it clear what they mean (and by clear here I mean precise for machine understanding). Minimally, an Action would have to be defined as producing an Event, which will need to be defined as a change in Property, all associated with a Thing. At least, that is how these concepts are associated in natural language and even in existing knowledge representation models. I went looking for these in the TD ontology and found nothing, no content model whatsoever beyond inheriting from DUL:Entity or owl:Thing.

So I fully accept the interest and need to have a common baseline model for servients, but it needs to be a real model and not just a placeholder. It is my understanding that actual integration with the semantic world is not of interest or even on the plate for the TD group.

To return to your example, you ask about units models such as MilliAmp. QUDT has a common name model for units that includes a possible multiplier attached to the unit name, so there is no incompatibility with the approach and need you describe. But where do units fall into the TD Actions, Events, Properties, and Things grouping? Properties could have a type, a dimension (there, after all, different standards), a quantity of that property that has a value that, itself, would have a dimensionless value and possibly a unit. But I do not see any of these concepts in The TD Property model.

I certainly agree that the IoT needs a Lingua Franca, but going back to the same old structure less approach doesn't bring clarity to system interactions. So once again I am confused about what question you were trying to ask or what point you were trying to make.

Jack Hodges

Sent from my iPad

<units.png>

[Dave Raggett]

On 2 Apr 2017, at 07:28, Jack Hodges <jhodg...@gmail.com> wrote:

Minimally, an Action would have to be defined as producing an Event, which will need to be defined as a change in Property, all associated with a Thing. At least, that is how these concepts are associated in natural language and even in existing knowledge representation models. I went looking for these in the TD ontology and found nothing, no content model whatsoever beyond inheriting from DUL:Entity or owl:Thing.

You seem to be assuming that actions just result in changes in property values. That isn’t the case. One example would be a 3D print service where a three dimensional shape is defined by streaming triangles to a thing’s property. The thing’s actions provide commands to start a new shape, to print the current shape, or to cancel the shape definition and/or print operation.  The thing’s object model defines the interface the thing exposes to applications. The semantics are defined separately. We don’t assume that applications require access to these semantic models. Nor is it assumed that the semantic model are defined in terms of atomic semantics. The semantic models just need to be sufficient for the purposes they will be used for, e.g. discovery, composition and validation.

[Dan Brickley]

Thanks for all this, Simon, Jason and all.

I'd like to explore how this might look in concrete instance data.
Let's avoid IoT for now and talk about the height of a specific person
as if it were a fairly timeless fact akin to date of birth (we would
naturally revisit this simplifying assumption later, e.g. for 'weight'
when looking at modeling date-stamped sensor readings with info about
instruments etc, later).

1. Here is a person height, using schema.org's GoodRelations-derrived
vocabulary:

{
"@context": "http://schema.org/",
"@type": "Person",
"name": "Jane Doe",
"height: {
"@type": "QuantitativeValue",
"unitCode": "MTR",
"value": "1.64"
}
}

2. As mentioned previously, schema.org also had an earlier structure
which (in pursuit of webmaster friendliness in microdata html syntax)
packed a unit code and value into a single string. The types currently
below http://schema.org/Quantity are in that tradition. So
http://schema.org/Distance e.g. is defined currently as "Properties
that take Distances as values are of the form '<Number> <Length unit
of measure>'. E.g., '7 ft'. There is no decent guidelines for what
these units of measure abbreviations should be, currently. They are
also modeled as subtypes of Intangible, even though they are presented
as if they were special kinds of textual string.

So we might expect .... in that old style,
{
"@context": "http://schema.org/",
"@type": "Person",
"name": "Jane Doe",
"height: "1.64 m"
}

....although since 'height' can take two different types
(QuantativeValue or Distance) this is also not super clear currently.


3. Revisiting these examples but taking more vocab and structure from
the QUDT example below, let's imagine the existing Distance type is
(re-)defined now as an instance of qudt:QuantityKind, hum let's say
DistanceInMetres and bake in the metres aspect:

schemaorg:DistanceInMetres a qudt:QuantityKind ;

qudt:applicableSIUnit unit:M ; qudt:generalization
quantitykind:Length; qudt:hasDimension qudt:DIM_SI-m ; rdfs:label
"Height" .

... then we might write


{
"@context": "http://schema.org/",
"@type": "Person",
"name": "Jane Doe",
"height: { "@type": "DistanceInMetres", "value": "1.64" },
}

... and have the articulation in terms of QUDT handled within the
schema.org definitions and not in user-facing instance data. I guess
we might get away with saying that our "height" property here is
rdfs:subPropertyOf qudt:hasQuantity, or some other association. Hmm
I've also cheated a bit by having the "height-node" quantity be of
"type" DistanceInMetres (aka HeightKind, below) rather than indicating
this via qudt:quantityKind. Is it possible for the
publisher-webmaster-developer facing instance data to be something
simple roughly following current complexity of schema.org, and have it
grounded with QUDT-powered definitions that live in reference files in
the schema.org schemas, rather than in the Web content?

What I've done with Distance[InMetres] above does not feel right as it
bakes into Distance an assumption that we're measuring in metres, but
it allows the instance data to be fairly simple (i.e. publishers don't
need to point to unit:M and or qudt:DIM_SI-m repeatedly); it would
push the repetition/redundancy into schema.org's definitions, assuming
we wanted kilometers, miles, centimetres, milimetres etc handled as
common ways of describing heights. Full QUDT in the instance data
should be fine too but it seems worth exploring shortcuts for common
cases.

Thinking out loud - and making mistakes I'm sure,

Dan

On 27 March 2017 at 09:17, <Simo...@csiro.au> wrote:
> Jason –
>
>
>
> You are not using the ‘QuantityKind’ apparatus.
>
> This is where the semantics (and dimensionality) of a Quantity are usually
> provided.
>
> Re-writing your example below to leverage this might be done in a couple of
> ways, both using a qudt:QuantityKind to provide the semantics of ‘Height’:
>
>
>
> ## QUDT – Option 1 – no subclass
>
> ```
>

> Turtle
>
> example:person1 qudt:hasQuantity example:height1 .
>
>
>

> example:HeightKind a qudt:QuantityKind ;
>
> qudt:applicableSIUnit unit:M ;
>
> qudt:generalization quantitykind:Length ;
>
> qudt:hasDimension qudt:DIM_SI-m ;
>
> rdfs:label "Height" ;
>
> .
>
>
>
> example:height1 a qudt:Quantity;
>
> qudt:quantityValue qudt:height_value1 ;
>

> qudt:quantiyKind example:HeightKind .

>
>
>
> example:height_value1 a qudt:QuantityValue;
>
> qudt:unit unit:CM;
>
> qudt:numericValue "180"^^dtype:numericUnion .
>
>
>
> ```
>
>
>

> ## QUDT – Option 2 – using a subclass
>
> ```
>
> Turtle
>
> # as above plus this sub-class definition
>
>
>
> example:HeightQuantity
>
> rdfs:subClassOf qudt:Quantity ;
>
> rdfs:subClassOf [
>
> rdf:type owl:Restriction ;
>
> owl:hasValue example:HeightKind ;
>
> owl:onProperty qudt:hasQuantityKind ;
>
> ] ;
>
> .
>
>
>
> example:height1 a qudt:Quantity , example:HeightQuantity ;
>

> qudt:quantityValue qudt:height_value1 .
>
>
>

> ```

>
>
>
>
>
> Simon
>
>
>
> From: Jason Koh [mailto:jb...@eng.ucsd.edu]
> Sent: Monday, 27 March, 2017 16:46
> To: Ralph TQ [Gmail] <rhod...@topquadrant.com>
> Cc: Dan Brickley <dan...@google.com>; Dave Raggett <d...@w3.org>;
> sdo-io...@googlegroups.com; Steve Ray <stev...@sv.cmu.edu>; Jack Hodges
> <jhodg...@gmail.com>; Cox, Simon (L&W, Clayton) <Simo...@csiro.au>;
> Jack Spivak <ja...@topquadrant.com>
> Subject: Re: QUDT, schema.org, IoT/WoT etc
>
>
>

[Jason Koh]

Hi Dan, 

Thanks for taking your time to review it. 

I agree we can make a schema:Quantity a type of schema:HeightKind other than having schema:HeightKind as a property. It will make easy to use it while mapping it to QUDT is still available (if we care.) However, I still think that separating units from qudtQuantityKind is more usable because units can easily explode as you mentioned. (Though it is quite subjective, I think publishers don't mind putting units in a separate property.) In the worst case, publishers may want to use an unknown units other than what we have. They should be able to indicate it no matter what it is so that we can easily process it at some point.

With regards,

Jason Koh

cseweb.ucsd.edu/~jbkoh

[Dan Brickley]

On 4 April 2017 at 21:23, Jason Koh <jb...@eng.ucsd.edu> wrote:
> Hi Dan,
>
> Thanks for taking your time to review it.
>
> I agree we can make a schema:Quantity a type of schema:HeightKind other than
> having schema:HeightKind as a property. It will make easy to use it while
> mapping it to QUDT is still available (if we care.) However, I still think
> that separating units from qudtQuantityKind is more usable because units can
> easily explode as you mentioned. (Though it is quite subjective, I think
> publishers don't mind putting units in a separate property.) In the worst
> case, publishers may want to use an unknown units other than what we have.
> They should be able to indicate it no matter what it is so that we can
> easily process it at some point.

Yes, we shouldn't take away that expressivity. Maybe special casing
for some common situations where a few units dominate, but schema.org
could do a much clearer job than currently in clarifying how to
specify units. Right now you might use "m" for temporal minutes, or
for miles or metres w.r.t. distance. We can and should do better than
that :)

Dan

[Dave Raggett]

Hi Dan,

I think we should distinguish the serialisation syntax from the semantics. Thus, whether you include the units as a suffix of the value or as a separate field is really a matter for the serialisation format.  For the semantics we need an unambiguous mapping to an agreed Linked Data vocabulary. 

Your examples use both MTR and m for metres. I see advantages for having standards for the names and abbreviations of units of measure as this will reduce the burden on everyone. This includes the scale factor, e.g. “mm” and “millimetres” as metres multiplied by a thousand. This also implies the need for a means to disambiguate abbreviations that have different interpretations in different contexts.

So I see value in having three categories of standards:

1. Names and abbreviations for units + scale factors, e.g. “mm” and “millimetres”, and broad groupings as a basis for disambiguation across different contexts.

2. The corresponding RDF URIs for the combination of units + scale factors.

3. An ontology that makes the scale factors explicit and relates different systems of measure, e.g. metric and imperial, to facilitate automatic conversions and enable semantic interoperability.

To make this clear: (1) refers to what is needed in JSON or HTML. (2) is needed in JSON-LD context declarations, and (3) is needed for semantic models that can be found by following the links implied by (2).

Best regards,

   Dave

[Dave Raggett]

On 5 Apr 2017, at 14:05, Ralph TQ [Gmail] <rhod...@topquadrant.com> wrote:

Some responses inline below to your email.

I will catch up and respond to other messages in due course.

One other consideration that I don’t think has been discussed is how data, particularly for IoT, needs to express encoding such as bit and byte order (big Endian and little Endian). Also the representation of bit fields. The telemetry work we did at NASA used the datatype ontologies of QUDT to represent these needs (see the DTYPE ontology at www.linked models.org  for a subset of this work).

That is indeed important, but is at a level below W3C’s work on the Web of Things where we decouple applications from the IoT standards for the underlying protocols and data formats.

Regards,

Ralph

On Apr 5, 2017, at 5:16 AM, Dave Raggett <d...@w3.org> wrote:

Hi Dan,

I think we should distinguish the serialisation syntax from the semantics. Thus, whether you include the units as a suffix of the value or as a separate field is really a matter for the serialisation format.  For the semantics we need an unambiguous mapping to an agreed Linked Data vocabulary. 

Your examples use both MTR and m for metres. I see advantages for having standards for the names and abbreviations of units of measure as this will reduce the burden on everyone. This includes the scale factor, e.g. “mm” and “millimetres” as metres multiplied by a thousand. This also implies the need for a means to disambiguate abbreviations that have different interpretations in different contexts.

QUDT uses well-known (if not standard) abbreviations for units. There are cases where this becomes counter-intuitive. For example “S” for siemens (https://en.wikipedia.org/wiki/Siemens_(unit))  and “SEC” for second.

At NASA we used the an encoded QName. For example, unit:KM.

So I see value in having three categories of standards:

1. Names and abbreviations for units + scale factors, e.g. “mm” and “millimetres”, and broad groupings as a basis for disambiguation across different contexts.

agreed

2. The corresponding RDF URIs for the combination of units + scale factors.

agrees - QUDT has a grammar for how to form the local names of URIs. The grammar includes prefixes.

3. An ontology that makes the scale factors explicit and relates different systems of measure, e.g. metric and imperial, to facilitate automatic conversions and enable semantic interoperability.

QUDT covers this

[Jason Koh]

All,

It's been a long time since the last discussion. I revitalize this issue again to materialize. (Not sure if I am behind the current status.)

I reviewed Dan's and Jack Spivak's suggestion.

Dan's: We need to keep the way to express units inside the schema name (E.g., DistanceInMetres) 

Jack's: We might want to make a light-weight QUDT.

(Please add more if I over-simplified.)

I like both ideas and, I'd like to make an agreement on the light-weight structure before diving into curating schema names with units. And I think Dan's structure was the simplest one for QUDT-Light.

{

 "@context": "http://schema.org/",

 "@type": "Person",

 "name": "Jane Doe",

 "height:  {   "@type": "Height",   "value": "1.64", "unit": "M" },

}

==

{

 "@context": "http://schema.org/",

 "@type": "Person",

 "name": "Jane Doe",

 "height:  {   "@type": "HeightInMetres",   "value": "1.64" },

}

(I changed Distance to Height to be more precise.)

If I describe this in a diagram with RDF, it will be like this:

​
​
The upper diagram is in schema.org or QUDT-Light and the below one is in the original QUDT. QUDT light version is sufficiently mappable to the original QUDT. Suggested QUDT-Light omits distinction among Quantity, QuantityKind, and QuantityValue. schema:Height corresponds to both qudt:Quantity and qudt:QuantityKind and a user instantiates it as :Height_1 and directly relate a unit and a value.

I need more investigation of if it is applicable to all cases in schema.org but it looks okay for now. 

I would like to listen to any ideas about: i) examples where this is not expressive enough, ii) whether this is intuitive enough for web masters (and IoT developers),  or iii) whether it loses necessary semantics.

With regards,

Jason Koh

cseweb.ucsd.edu/~jbkoh