Open dr-shorthair opened 3 years ago
+1 on @dr-shorthair 's request. I'm working in https://github.com/w3c-ccg/traceability-vocab and we're considering QUDT for handling global, generic measurement values in the trade/supply chain space. I was looking for JSON-LD examples, not finding any so far. @dr-shorthair 's point seems to explain why - and worries me. Any strategic JSON-LD support or even just pointers how we might go about implementation would be much appreciated.
If I understand your request, are you asking, for example, http://qudt.org/vocab/unit/A to resolve to not only Turtle, but also to JSON and/or JSON-LD, depending on the http header?
Saying it another way, are you:
or
@steveraysteveray, thank you for your response. In fact what I meant to be asking is much simpler: I am really just looking for a JSON(-LD) example where QUDT is being put in use (realizing now that my question was poorly worded, this is about usage, not support).
10 amps
look like in a JSON object? Thanks again. I'm keen to start using QUDT.
I'm not expert in using JSON, so perhaps @dr-shorthair can generate an example?
To address your question 1 above in a pedantic way, nothing will be "of type http://qudt.org/vocab/unit/A" because http://qudt.org/vocab/unit/A is not a class, just an instance of qudt:Unit. (I know that's not really what you are after...)
@steveraysteveray
I think @nissimsan might be asking if the QUDT vocabulary can be published not only in Turtle but also in JSON-LD. Here's a snippet of what this might look like (only showing the entry for milligram):
{
"@context": {
"dc": "http://purl.org/dc/elements/1.1/",
"dcterms": "http://purl.org/dc/terms/",
"owl": "http://www.w3.org/2002/07/owl#",
"prov": "http://www.w3.org/ns/prov#",
"qkdv": "http://qudt.org/vocab/dimensionvector/",
"quantitykind": "http://qudt.org/vocab/quantitykind/",
"qudt": "http://qudt.org/schema/qudt/",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"skos": "http://www.w3.org/2004/02/skos/core#",
"sou": "http://qudt.org/vocab/sou/",
"unit": "http://qudt.org/vocab/unit/",
"vaem": "http://www.linkedmodel.org/schema/vaem#",
"voag": "http://voag.linkedmodel.org/schema/voag#",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"a": "@type"
},
"@graph": [
{
"@id": "unit:MilliGM",
"a": "qudt:Unit",
"qudt:conversionMultiplier": 0.000001 ,
"qudt:hasDimensionVector": "qkdv:A0E0L0I0M1H0T0D0" ,
"qudt:hasQuantityKind": "quantitykind:Mass" ,
"qudt:iec61360Code": "0112/2///62720#UAA815" ,
"qudt:plainTextDescription": "0.000001-fold of the SI base unit kilogram" ,
"qudt:ucumCode": {"@value":"mg","@type":"qudt:UCUMcs"} ,
"qudt:uneceCommonCode": "MGM" ,
"rdfs:isDefinedBy": "http://qudt.org/2.1/vocab/unit" ,
"rdfs:label": {"@value":"Milligram","@language":"en"}
}
]
}
This correctly translates back to the current triples already provided by QUDT in Turtle,
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix qkdv: <http://qudt.org/vocab/dimensionvector/> .
@prefix quantitykind: <http://qudt.org/vocab/quantitykind/> .
@prefix qudt: <http://qudt.org/schema/qudt/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix sou: <http://qudt.org/vocab/sou/> .
@prefix unit: <http://qudt.org/vocab/unit/> .
@prefix vaem: <http://www.linkedmodel.org/schema/vaem#> .
@prefix voag: <http://voag.linkedmodel.org/schema/voag#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
unit:MilliGM
a qudt:Unit ;
qudt:conversionMultiplier 0.000001 ;
qudt:hasDimensionVector qkdv:A0E0L0I0M1H0T0D0 ;
qudt:hasQuantityKind quantitykind:Mass ;
qudt:iec61360Code "0112/2///62720#UAA815" ;
qudt:plainTextDescription "0.000001-fold of the SI base unit kilogram" ;
qudt:ucumCode "mg"^^qudt:UCUMcs ;
qudt:uneceCommonCode "MGM" ;
rdfs:isDefinedBy http://qudt.org/2.1/vocab/unit ;
rdfs:label "Milligram"@en ;
(@steveraysteveray - you can verify that by pasting the previous JSON-LD snippet into https://json-ld.org/playground/ then clicking on the N-Quads or Normalised tabs.)
I've tried to keep the JSON-LD example above structurally very similar to the Turtle, so whatever script is generating the Turtle output can probably be modified fairly easily to generate the equivalent JSON-LD. Essentially each definition would be a new curly-bracket element within the square bracket array shown as the value of "@graph"
. We can of course enhance the JSON-LD context to hide/alias some of the JSON-LD keywords that begin with "@" to make it even easier to process as JSON, even by anyone without any specific understanding or interest in JSON-LD.
I hope this helps.
@nissimsan really cares about the usability and fixed shape of JSONLD payload. https://github.com/w3c-ccg/traceability-vocab/tree/main/docs/openapi/components/schemas/common are 92 JSON schemas in YAML format, covering Agriculture, Products, Organizations, LEI, BizCards and Contacts, Electronic Bill of Lading, IATA AirWayBill, Oil & Gas, Mechanical and Chemical properties, etc. They don't just define what data is expected, but the precise frame (shape) of the data.
So @mgh128 and @steveraysteveray A richer context will be nicer. Eg (quotes omitted for laziness):
rdfs:isDefinedBy: {@type: @id}, // else comes out as string
qudt:ucumCode: {@type: qudt:UCUMcs} // so we don't need that type in payload
rdfs:label: {container: language} // so one can use rdfs:label: {en: "Milligram"}, or even
rdfs:label: {language: en} // so one can use merely rdfs:label: "Milligram"
But wait, why am I explaining this to TopQuadrant!
http://qudt.org/vocab/unit/A has View as: CSV RDF/XML TURTLE JSON JSON-LD
at the bottom, and the JSONLD has a lot of these niceties.
@steveraysteveray:
http://qudt.org/vocab/unit/A View as: ... JSON-LD
is nearly what's needed, but with the following corrections:
curl -Haccept:application/ld+json http://qudt.org/vocab/unit/A
curl http://qudt.org/vocab/unit/context.jsonld
curl -Haccept:application/ld+json http://qudt.org/vocab/unit/ # this is how schema.org does it
Please also add entity serving and content negotiation for CSV
and TURTLE
, please!
About the remaining 2 content types:
JSON
, it's a weird thing with keys being phrases, and is syntactically invalid because of duplicate keys:
"allowed unit of system":"sou:CGS-EMU"
,"allowed unit of system":"sou:CGS-GAUSS"
,"allowed unit of system":"sou:PLANCK"
RDF/XML
, nobody likes it@nissimsan
What does 10 amps look like in a JSON object?
Using https://schema.org/QuantitativeValue or https://schema.org/PropertyValue, and appropriate prefixes, you could go like this (expressing 10.3 Amps, but considerable extra detail):
measuredValue: {
schema:minValue 12.2,
schema:value: 12.3,
schema:maxValue 12.4,
schema:unit: unit:A, // prop from Schema, individual from QUDT
schema:measurementTechnique: "Amper-meter, made by Bosch, tolerance 0.1A"
}
@steveraysteveray Could you show an example using QUDT props for value & unit?
Can I specify in a JSON Schema that a certain element is of type [uses unit] http://qudt.org/vocab/unit/A?
No. What you mean is a default unit for a value. You could have that:
:amperage a owl:DataProperty
rdf:range xsd:decimal;
:unit unit:A. # :unit is the annotation property
@dr-shorthair @steveraysteveray
TTL is just a serialization of the underlying graph, and JSON-LD is just another one.
I thought the same but JSON-LD 1.1 makes JSON sing and dance (think contexts scoped to a prop or a class). Which is important when you consider folks who use JSON Schema, or Verifiable Certificate signing, etc.
And in both cases there are multiple ways that they could be laid out that are logically equivalent.
Yes, but only humans care how Turtle is laid out, whereas machines care a lot about how JSON is laid out.
keep the webbies happy?
Do I smell some derision? Just kidding.
QUDT is pretty regular (the rdf representation of Units, anyway) so JSONLD generation should not present much difficulty.
JSON-LD 1.1 makes JSON sing and dance
Good to know. I haven't really worked much with JSON or JSON-LD, so don't know what 1.1 added.
I am aware that the JSON meta-model is not the same as RDF so there is a risk that serialization choices can break things :-(
The webbies are important. I'm not one of them but I would like to make them happy.
so whatever script is generating the Turtle output can probably be modified fairly easily to generate the equivalent JSON-LD
I assume this is in the TopQuadrant engine? I know that does support JSON-LD, so it should be easily added.
I'm working with a team in CSIRO to routinely use some external vocabulary services, including QUDT's catalogues. We are testing to see what formats/representations are available, in particular JSON. Currently QUDT politely declines to serve JSON or JSON-LD, with a 406. Would it be possible to flick a switch somewhere to turn JSON on?