SlideShare una empresa de Scribd logo
JSON-LD
Minimal generic standard RDF format
for definition and exchange of
ontologies/taxonomies/glossaries
Michal Miklas
2020-02-20
JSON-LD
https://www.w3.org/TR/json-ld11/
JSON-LD is designed to be usable directly as JSON, with no knowledge of RDF [RDF11-
CONCEPTS]. It is also designed to be usable as RDF in conjunction with other Linked Data
technologies like SPARQL [SPARQL11-OVERVIEW]. Developers who require any of the
facilities listed above or need to serialize an RDF graph or Dataset in a JSON-based syntax
will find JSON-LD of interest. People intending to use JSON-LD with RDF tools will find it
can be used as another RDF syntax, as with [Turtle] and [TriG]. Complete details of how
JSON-LD relates to RDF are in section § 10. Relationship to RDF:
https://www.w3.org/TR/json-ld11/#relationship-to-rdf
Glossaries
explored
Schema.org – simple enough, based on rdf/rdfs, (class, property, subclass), but has custom domain and range
constructs. Mostly missing: category/container type for grouping of terms. Schema metamodel types (e.g. class
& property) are however not used as types in the json-ld, instead it relies on rfd: / rdfs: )
https://schema.org/version/6.0/all-layers.jsonld
CIM – custom constructs in the json-ld (aliases within context section) that are not part of rdf/rdfs or other w3
standard, e.g.: subjectArea, entityGroups, classConcepts, propertyConcepts, schemas. Also additional custom
aliases: name -> rdfs:label, description -> rdfs:comment
https://cloudinformationmodel.org/dist/model.jsonld
Gs1 (extending schema.org) – appropriate format, but maybe too many namespaces from which some of them
are only used very little within the definitions, still some of them useful e.g. “dc:”
https://www.gs1.org/docs/gs1-smartsearch/gs1Voc_v1_2.jsonld
Json-ld
Two main sections:
• Context
• Graph
Good example:
• https://www.gs1.org/docs/gs1-smartsearch/gs1Voc_v1_2.jsonld
Json-ld rdf triple
store context
Context defines the namespaces and the aliases of the types used in the triple store definitions of
object (graph)
"@context": {
"owl": "http://www.w3.org/2002/07/owl#", <- optional
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#", <- core
"rdfs": "http://www.w3.org/2000/01/rdf-schema#", <- core
"sh": "http://www.w3.org/ns/shacl#", <- optional
"skos": "http://www.w3.org/2004/02/skos/core#", <- optional
"xsd": "http://www.w3.org/2001/XMLSchema#" <- core
}
SHACL and OWL
Compared
• https://spinrdf.org/shacl-and-owl.html
• The article explains how the OWL and SHACL can
coexist for backward compatibility that would use
OWL only
• Assuming here three files:
1. pure RDF/RDFS
2. OWL extensions (optional)
3. SHACL extensions (optional)
• Assuming it would work for JSON-LD the same
way as described fro TTL in the article
Json-ld rdf triple
store - graph
• Graph is just an array of the json objects
"@graph": [
{"@id": "Product", "@type": ["rdfs:Class“]},
{"@id": “Color", "@type": ["rdf:Property"]},
{"@id": “Customer Managment", "@type": ["rdfs:Container"]}
]
Minimum of
rdf/rdfs types used
• rdfs:class – for concepts, terms, entities, types
• rdf:property – for descriptive characteristics of above
• rdfs:container – for groups of classes and properties (not exhaustive unorder collections)
• rdfs:member – for allocation of classes and properties to containers
• rdfs:comment – object description
• rdfs:label – object name
• rdfs:subClassOf – supertype of class – a reference to another class
• rdfs:domain – property owning class
• rdfs:range – property (data or object) type – reference to a class if object
• xsd:* primitive data types
Optional OWL/SHACL
constructs
• owl:Class (in addition to rdfs:Class)
• owl:ObjectProperty (in addition to rdf:Property)
• owl:DataProperty (in addition to rdf:Property)
• owl:FunctionalProperty (in addition to owl:ObjectProperty, owl:DataProperty, rdf:Property ) –
defines the property as unique identifier
• owl:Ontology – for definition of the whole glossary/vocabulary/model
• sh:shape (in addition to rdfs:Class)
• sh:property (in addition to rdf:Property)
• owl:minCardinality or sh:minCount
• owl:maxCardinality or sh:maxCount
• sh:path – defines property name - seems like equivalent to rdfs:label on rdf:Property
Optional potentially
useful types
• rdfs:seeAlso (if links to external glossaries – or other open standards are provided)
• owl:sameAs
• skos:exactMatch (if links to external glossaries – or other open standards are included in the definition
of glossary/ontology)
• skos:altLabel - for alternative names
• Other for consideration:
• skos:collection vs rdfs:container
https://www.w3.org/wiki/SkosDev/SkosCore/CollectionsAndArrays
• sh:datatype – not sure about advantage of this over range on property with xsd data type
• skos:example
Exclusions and
other
considerations
• For sake of simplicity would not consider these constructs:
• Property subtyping
• Inverse of ( for example as defined for object property in schema.org)
• Superseded by
• Required custom attribute - need to find whether appropriate constructs exist in
existing namespaces
• Alternate names (only see something like this in schema.org but no in a
w3 standard)
• Identifier (only see something like this in schema.org but no in a w3
standard)
• Labels – can we use categories?
• How to model custom relationships e.g. between properties, for example
“calculated from” or “derived from”?
• Should it be possible to use the schema.org the same way as rdf/rdfs/owl? Or
just for extending its content – what I mean that schema.org is not used as
metamodel, hence the schema:* is never used for @type in gs1 for example.
Container
{
"@id": “im-banking:Product Analysis",
"@type": "rdfs:Container" ,
"rdfs:comment": {
"@language": "en",
"@value": “Grouping of concepts – both classes and
properties – used for analysis of the product."
},
"rdfs:label": {
"@language": "en",
"@value": “Product Analysis“
},
"rdfs:member {"@id": "im-banking:Customer
Management“}
}
Class
{
"@id": “im-banking:Financial Product",
"@type": "rdfs:Class",
"rdfs:comment": {
"@language": "en",
"@value": " Goods and services that can be offered,
sold or purchased by the financial Institution."
},
"rdfs:label": {
"@language": "en",
"@value": “Product"
},
"rdfs:subClassOf": { "@id": "im-banking:Product“ },
"rdfs:member": [ {"@id": "im-banking:Product
Analysis"},
{"@id": "im-banking:Customer
Management"} ]
}
Property – data
property (range
= primitive data
type)
{
"@id": “im-banking:Unit Price",
"@type": "rdfs:Property",
"rdfs:comment": {
"@language": "en",
"@value": "Unit price as set by the organization for
goods and services sold."
},
"rdfs:label": {
"@language": "en",
"@value": “Unit Price"
},
"rdfs:domain": { "@id": "im-banking:Product" },
"rdfs:range": { "@id": "xsd:float"},
"rdfs:member": [ {"@id": "im-banking:Product
Analysis"},
{"@id": "im-banking:Customer
Management"} ]
},
Property –
object property
(range = class)
{
"@id": “im-banking:Product Owner",
"@type": [ "rdfs:Property " ],
"rdfs:comment": {
"@language": "en",
"@value": “Company who developed and sells the
product."
},
"rdfs:label": {
"@language": "en",
"@value": “Product Owner"
},
"rdfs:domain": { "@id": "im-banking:Product"},
"rdfs:range": { "@id": "im-banking:Organization"},
"rdfs:member": {"@id": "im-banking:Product
Analysis"}
},
Industry
Models
Glossaries
• Each Industry glossary could be defined
within its own namespace
• Would probably settle on one json-ld per
industry/namespace
• For example:
• im-banking:
• im-insurance:
• im-healthcare:
• im-energy:
• Each namespace represents a separate
glossary/vocabulary
GS1 glossary definition
- useful section but rellies on too many namespaces just for definition of the glossary object
- might be necessary to include it all in similar fassion
{
"@id": "gs1:",
"@type": [
"voaf:Vocabulary",
"owl:Ontology"
],
"schema:license": "data:text/html;charset=UTF-
8,<p>GS1&reg;, under its IP Policy, seeks to avoid
uncertainty regarding intellectual property claims by
requiring the participants in the Work Groups that
developed this vocabulary to agree to grant to GS1
members a royalty-free licence or a RAND licence to
Necessary Claims, as that term is defined in the GS1 IP
Policy. Furthermore, attention is drawn to the possibility
that an implementation of one or more features of this
vocabulary may be the subject of a patent or other
intellectual property right that does not involve a
Necessary Claim. Any such patent or other intellectual
property right is not subject to the licencing obligations of
GS1. Moreover, the agreement to grant licences provided
under the GS1 IP Policy does not include IP rights and any
claims of third parties who were not participants in the
Work Groups. Accordingly, GS1 recommends that any
organisation developing an implementation designed to be
in conformance with this vocabulary should determine
whether there are any patents that may encompass a
specific implementation that the organisation is developing
in compliance with the vocabulary and whether a licence
under a patent or other intellectual property right is needed.
Such a determination of a need for licencing should be made
in view of the details of the specific system designed by the
organisation in consultation with their own patent counsel.
THIS DOCUMENT IS PROVIDED &quot;AS IS&quot; WITH NO
WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY
OF MERCHANTABILITY, NONINFRINGMENT, FITNESS FOR
PARTICULAR PURPOSE, OR ANY WARRANTY OTHER WISE
ARISING OUT OF THIS SPECIFICATION. GS1 disclaims all
liability for any damages arising from use or misuse of this
vocabulary, whether special, indirect, consequential, or
compensatory damages, and including liability for
infringement of any intellectual property rights, relating to
use of information in or reliance upon this document. GS1
retains the right to make changes to this vocabulary at any
time, without notice. GS1 makes no warranty for the use of
this vocabulary and assumes no responsibility for any errors
which may appear in the vocabulary, nor does it make a
commitment to update the information contained herein.
GS1 and the GS1 logo are registered trademarks of GS1
AISBL.</p><p>Copyright 2015-2019 GS1
AISBL</p><p>Licensed under the Apache License, Version
2.0 (the &quot;License&quot;); you may not use this file
except in compliance with the License. You may obtain a
copy of the License at <a
href=&quot;http://www.apache.org/licenses/LICENSE-
2.0&quot;
target=&quot;blank&quot;>http://www.apache.org/licenses
/LICENSE-2.0</a>.<p><p>Unless required by applicable law
or agreed to in writing, software distributed under the
License is distributed on an &quot;AS IS&quot; BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
either express or implied. See the License for the specific
language governing permissions and limitations under the
License.</p>",
"dc:contributors": "Eric Kauz, Mark Harrison, Phil
Archer",
"dc:creator": {
"@id": "https://www.gs1.org/"
},
"dc:description:": {
"@language": "en",
"@value": "The GS1 RDF vocabulary, described using
W3C RDF Schema and the Web Ontology Language. The
vocabulary builds on and refers to schema.org where
appropriate."
},
"dc:identifier:": "GS1 Vocabulary",
"dc11:title": "GS1 Vocabulary",
"dc:issued:": {
"@type": "xsd:date",
"@value": "2017-11-20"
},
"dc:lastModified": {
"@type": "xsd:date",
"@value": "2019-12-01"
},
"owl:versionInfo": "1.2",
"vann:preferredNamespacePrefix": "gs1",
"vann:preferredNamespaceUri": {
"@id": "gs1:"
},
"voaf:extends": {
"@id": "schema:"
},
"voaf:hasEquivalencesWith": {
"@id": "schema:"
},
"voaf:specializes": {
"@id": "schema:"
}
}
RDF & OWL overview diagrams
https://www.infowebml.ws/rdf-owl/graphical-representations.htm

Más contenido relacionado

Similar a 20th Feb 2020 json-ld-rdf-im-proposal.pdf

A hands on overview of the semantic web
A hands on overview of the semantic webA hands on overview of the semantic web
A hands on overview of the semantic web
Marakana Inc.
 
Tutorial: Describing Datasets with the Health Care and Life Sciences Communit...
Tutorial: Describing Datasets with the Health Care and Life Sciences Communit...Tutorial: Describing Datasets with the Health Care and Life Sciences Communit...
Tutorial: Describing Datasets with the Health Care and Life Sciences Communit...
Alasdair Gray
 
Dev8d Apache Solr Tutorial
Dev8d Apache Solr TutorialDev8d Apache Solr Tutorial
Dev8d Apache Solr Tutorial
Sourcesense
 

Similar a 20th Feb 2020 json-ld-rdf-im-proposal.pdf (20)

SKOS - 2007 Open Forum on Metadata Registries - NYC
SKOS - 2007 Open Forum on Metadata Registries - NYCSKOS - 2007 Open Forum on Metadata Registries - NYC
SKOS - 2007 Open Forum on Metadata Registries - NYC
 
A hands on overview of the semantic web
A hands on overview of the semantic webA hands on overview of the semantic web
A hands on overview of the semantic web
 
Elasticsearch & "PeopleSearch"
Elasticsearch & "PeopleSearch"Elasticsearch & "PeopleSearch"
Elasticsearch & "PeopleSearch"
 
Tutorial: Describing Datasets with the Health Care and Life Sciences Communit...
Tutorial: Describing Datasets with the Health Care and Life Sciences Communit...Tutorial: Describing Datasets with the Health Care and Life Sciences Communit...
Tutorial: Describing Datasets with the Health Care and Life Sciences Communit...
 
RDFa Introductory Course Session 2/4 How RDFa
RDFa Introductory Course Session 2/4 How RDFaRDFa Introductory Course Session 2/4 How RDFa
RDFa Introductory Course Session 2/4 How RDFa
 
How RDFa works
How RDFa worksHow RDFa works
How RDFa works
 
RDF SHACL, Annotations, and Data Frames
RDF SHACL, Annotations, and Data FramesRDF SHACL, Annotations, and Data Frames
RDF SHACL, Annotations, and Data Frames
 
HyperGraphQL
HyperGraphQLHyperGraphQL
HyperGraphQL
 
Triplificating and linking XBRL financial data
Triplificating and linking XBRL financial dataTriplificating and linking XBRL financial data
Triplificating and linking XBRL financial data
 
CTDA MODS and Islandora XML Forms
CTDA MODS and Islandora XML FormsCTDA MODS and Islandora XML Forms
CTDA MODS and Islandora XML Forms
 
Danbri Drupalcon Export
Danbri Drupalcon ExportDanbri Drupalcon Export
Danbri Drupalcon Export
 
RDFa Semantic Web
RDFa Semantic WebRDFa Semantic Web
RDFa Semantic Web
 
RDFa: introduction, comparison with microdata and microformats and how to use it
RDFa: introduction, comparison with microdata and microformats and how to use itRDFa: introduction, comparison with microdata and microformats and how to use it
RDFa: introduction, comparison with microdata and microformats and how to use it
 
Semantic Web talk TEMPLATE
Semantic Web talk TEMPLATESemantic Web talk TEMPLATE
Semantic Web talk TEMPLATE
 
RDFa Tutorial
RDFa TutorialRDFa Tutorial
RDFa Tutorial
 
The Semantic Web #9 - Web Ontology Language (OWL)
The Semantic Web #9 - Web Ontology Language (OWL)The Semantic Web #9 - Web Ontology Language (OWL)
The Semantic Web #9 - Web Ontology Language (OWL)
 
JSON in der Oracle Datenbank
JSON in der Oracle DatenbankJSON in der Oracle Datenbank
JSON in der Oracle Datenbank
 
LinkML presentation to Yosemite Group
LinkML presentation to Yosemite GroupLinkML presentation to Yosemite Group
LinkML presentation to Yosemite Group
 
DC-2008 Tutorial 3 - Dublin Core and other metadata schemas
DC-2008 Tutorial 3 - Dublin Core and other metadata schemasDC-2008 Tutorial 3 - Dublin Core and other metadata schemas
DC-2008 Tutorial 3 - Dublin Core and other metadata schemas
 
Dev8d Apache Solr Tutorial
Dev8d Apache Solr TutorialDev8d Apache Solr Tutorial
Dev8d Apache Solr Tutorial
 

Último

Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo DiehlFuture Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Peter Udo Diehl
 

Último (20)

ECS 2024 Teams Premium - Pretty Secure
ECS 2024   Teams Premium - Pretty SecureECS 2024   Teams Premium - Pretty Secure
ECS 2024 Teams Premium - Pretty Secure
 
Behind the Scenes From the Manager's Chair: Decoding the Secrets of Successfu...
Behind the Scenes From the Manager's Chair: Decoding the Secrets of Successfu...Behind the Scenes From the Manager's Chair: Decoding the Secrets of Successfu...
Behind the Scenes From the Manager's Chair: Decoding the Secrets of Successfu...
 
Knowledge engineering: from people to machines and back
Knowledge engineering: from people to machines and backKnowledge engineering: from people to machines and back
Knowledge engineering: from people to machines and back
 
AI revolution and Salesforce, Jiří Karpíšek
AI revolution and Salesforce, Jiří KarpíšekAI revolution and Salesforce, Jiří Karpíšek
AI revolution and Salesforce, Jiří Karpíšek
 
IESVE for Early Stage Design and Planning
IESVE for Early Stage Design and PlanningIESVE for Early Stage Design and Planning
IESVE for Early Stage Design and Planning
 
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered Quality
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualitySoftware Delivery At the Speed of AI: Inflectra Invests In AI-Powered Quality
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered Quality
 
WSO2CONMay2024OpenSourceConferenceDebrief.pptx
WSO2CONMay2024OpenSourceConferenceDebrief.pptxWSO2CONMay2024OpenSourceConferenceDebrief.pptx
WSO2CONMay2024OpenSourceConferenceDebrief.pptx
 
Demystifying gRPC in .Net by John Staveley
Demystifying gRPC in .Net by John StaveleyDemystifying gRPC in .Net by John Staveley
Demystifying gRPC in .Net by John Staveley
 
Transforming The New York Times: Empowering Evolution through UX
Transforming The New York Times: Empowering Evolution through UXTransforming The New York Times: Empowering Evolution through UX
Transforming The New York Times: Empowering Evolution through UX
 
The architecture of Generative AI for enterprises.pdf
The architecture of Generative AI for enterprises.pdfThe architecture of Generative AI for enterprises.pdf
The architecture of Generative AI for enterprises.pdf
 
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo DiehlFuture Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
 
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
 
Speed Wins: From Kafka to APIs in Minutes
Speed Wins: From Kafka to APIs in MinutesSpeed Wins: From Kafka to APIs in Minutes
Speed Wins: From Kafka to APIs in Minutes
 
Powerful Start- the Key to Project Success, Barbara Laskowska
Powerful Start- the Key to Project Success, Barbara LaskowskaPowerful Start- the Key to Project Success, Barbara Laskowska
Powerful Start- the Key to Project Success, Barbara Laskowska
 
Connecting the Dots in Product Design at KAYAK
Connecting the Dots in Product Design at KAYAKConnecting the Dots in Product Design at KAYAK
Connecting the Dots in Product Design at KAYAK
 
Integrating Telephony Systems with Salesforce: Insights and Considerations, B...
Integrating Telephony Systems with Salesforce: Insights and Considerations, B...Integrating Telephony Systems with Salesforce: Insights and Considerations, B...
Integrating Telephony Systems with Salesforce: Insights and Considerations, B...
 
Designing for Hardware Accessibility at Comcast
Designing for Hardware Accessibility at ComcastDesigning for Hardware Accessibility at Comcast
Designing for Hardware Accessibility at Comcast
 
IoT Analytics Company Presentation May 2024
IoT Analytics Company Presentation May 2024IoT Analytics Company Presentation May 2024
IoT Analytics Company Presentation May 2024
 
Intelligent Gimbal FINAL PAPER Engineering.pdf
Intelligent Gimbal FINAL PAPER Engineering.pdfIntelligent Gimbal FINAL PAPER Engineering.pdf
Intelligent Gimbal FINAL PAPER Engineering.pdf
 
Introduction to Open Source RAG and RAG Evaluation
Introduction to Open Source RAG and RAG EvaluationIntroduction to Open Source RAG and RAG Evaluation
Introduction to Open Source RAG and RAG Evaluation
 

20th Feb 2020 json-ld-rdf-im-proposal.pdf

  • 1. JSON-LD Minimal generic standard RDF format for definition and exchange of ontologies/taxonomies/glossaries Michal Miklas 2020-02-20
  • 2. JSON-LD https://www.w3.org/TR/json-ld11/ JSON-LD is designed to be usable directly as JSON, with no knowledge of RDF [RDF11- CONCEPTS]. It is also designed to be usable as RDF in conjunction with other Linked Data technologies like SPARQL [SPARQL11-OVERVIEW]. Developers who require any of the facilities listed above or need to serialize an RDF graph or Dataset in a JSON-based syntax will find JSON-LD of interest. People intending to use JSON-LD with RDF tools will find it can be used as another RDF syntax, as with [Turtle] and [TriG]. Complete details of how JSON-LD relates to RDF are in section § 10. Relationship to RDF: https://www.w3.org/TR/json-ld11/#relationship-to-rdf
  • 3. Glossaries explored Schema.org – simple enough, based on rdf/rdfs, (class, property, subclass), but has custom domain and range constructs. Mostly missing: category/container type for grouping of terms. Schema metamodel types (e.g. class & property) are however not used as types in the json-ld, instead it relies on rfd: / rdfs: ) https://schema.org/version/6.0/all-layers.jsonld CIM – custom constructs in the json-ld (aliases within context section) that are not part of rdf/rdfs or other w3 standard, e.g.: subjectArea, entityGroups, classConcepts, propertyConcepts, schemas. Also additional custom aliases: name -> rdfs:label, description -> rdfs:comment https://cloudinformationmodel.org/dist/model.jsonld Gs1 (extending schema.org) – appropriate format, but maybe too many namespaces from which some of them are only used very little within the definitions, still some of them useful e.g. “dc:” https://www.gs1.org/docs/gs1-smartsearch/gs1Voc_v1_2.jsonld
  • 4. Json-ld Two main sections: • Context • Graph Good example: • https://www.gs1.org/docs/gs1-smartsearch/gs1Voc_v1_2.jsonld
  • 5. Json-ld rdf triple store context Context defines the namespaces and the aliases of the types used in the triple store definitions of object (graph) "@context": { "owl": "http://www.w3.org/2002/07/owl#", <- optional "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#", <- core "rdfs": "http://www.w3.org/2000/01/rdf-schema#", <- core "sh": "http://www.w3.org/ns/shacl#", <- optional "skos": "http://www.w3.org/2004/02/skos/core#", <- optional "xsd": "http://www.w3.org/2001/XMLSchema#" <- core }
  • 6. SHACL and OWL Compared • https://spinrdf.org/shacl-and-owl.html • The article explains how the OWL and SHACL can coexist for backward compatibility that would use OWL only • Assuming here three files: 1. pure RDF/RDFS 2. OWL extensions (optional) 3. SHACL extensions (optional) • Assuming it would work for JSON-LD the same way as described fro TTL in the article
  • 7. Json-ld rdf triple store - graph • Graph is just an array of the json objects "@graph": [ {"@id": "Product", "@type": ["rdfs:Class“]}, {"@id": “Color", "@type": ["rdf:Property"]}, {"@id": “Customer Managment", "@type": ["rdfs:Container"]} ]
  • 8. Minimum of rdf/rdfs types used • rdfs:class – for concepts, terms, entities, types • rdf:property – for descriptive characteristics of above • rdfs:container – for groups of classes and properties (not exhaustive unorder collections) • rdfs:member – for allocation of classes and properties to containers • rdfs:comment – object description • rdfs:label – object name • rdfs:subClassOf – supertype of class – a reference to another class • rdfs:domain – property owning class • rdfs:range – property (data or object) type – reference to a class if object • xsd:* primitive data types
  • 9. Optional OWL/SHACL constructs • owl:Class (in addition to rdfs:Class) • owl:ObjectProperty (in addition to rdf:Property) • owl:DataProperty (in addition to rdf:Property) • owl:FunctionalProperty (in addition to owl:ObjectProperty, owl:DataProperty, rdf:Property ) – defines the property as unique identifier • owl:Ontology – for definition of the whole glossary/vocabulary/model • sh:shape (in addition to rdfs:Class) • sh:property (in addition to rdf:Property) • owl:minCardinality or sh:minCount • owl:maxCardinality or sh:maxCount • sh:path – defines property name - seems like equivalent to rdfs:label on rdf:Property
  • 10. Optional potentially useful types • rdfs:seeAlso (if links to external glossaries – or other open standards are provided) • owl:sameAs • skos:exactMatch (if links to external glossaries – or other open standards are included in the definition of glossary/ontology) • skos:altLabel - for alternative names • Other for consideration: • skos:collection vs rdfs:container https://www.w3.org/wiki/SkosDev/SkosCore/CollectionsAndArrays • sh:datatype – not sure about advantage of this over range on property with xsd data type • skos:example
  • 11. Exclusions and other considerations • For sake of simplicity would not consider these constructs: • Property subtyping • Inverse of ( for example as defined for object property in schema.org) • Superseded by • Required custom attribute - need to find whether appropriate constructs exist in existing namespaces • Alternate names (only see something like this in schema.org but no in a w3 standard) • Identifier (only see something like this in schema.org but no in a w3 standard) • Labels – can we use categories? • How to model custom relationships e.g. between properties, for example “calculated from” or “derived from”? • Should it be possible to use the schema.org the same way as rdf/rdfs/owl? Or just for extending its content – what I mean that schema.org is not used as metamodel, hence the schema:* is never used for @type in gs1 for example.
  • 12. Container { "@id": “im-banking:Product Analysis", "@type": "rdfs:Container" , "rdfs:comment": { "@language": "en", "@value": “Grouping of concepts – both classes and properties – used for analysis of the product." }, "rdfs:label": { "@language": "en", "@value": “Product Analysis“ }, "rdfs:member {"@id": "im-banking:Customer Management“} }
  • 13. Class { "@id": “im-banking:Financial Product", "@type": "rdfs:Class", "rdfs:comment": { "@language": "en", "@value": " Goods and services that can be offered, sold or purchased by the financial Institution." }, "rdfs:label": { "@language": "en", "@value": “Product" }, "rdfs:subClassOf": { "@id": "im-banking:Product“ }, "rdfs:member": [ {"@id": "im-banking:Product Analysis"}, {"@id": "im-banking:Customer Management"} ] }
  • 14. Property – data property (range = primitive data type) { "@id": “im-banking:Unit Price", "@type": "rdfs:Property", "rdfs:comment": { "@language": "en", "@value": "Unit price as set by the organization for goods and services sold." }, "rdfs:label": { "@language": "en", "@value": “Unit Price" }, "rdfs:domain": { "@id": "im-banking:Product" }, "rdfs:range": { "@id": "xsd:float"}, "rdfs:member": [ {"@id": "im-banking:Product Analysis"}, {"@id": "im-banking:Customer Management"} ] },
  • 15. Property – object property (range = class) { "@id": “im-banking:Product Owner", "@type": [ "rdfs:Property " ], "rdfs:comment": { "@language": "en", "@value": “Company who developed and sells the product." }, "rdfs:label": { "@language": "en", "@value": “Product Owner" }, "rdfs:domain": { "@id": "im-banking:Product"}, "rdfs:range": { "@id": "im-banking:Organization"}, "rdfs:member": {"@id": "im-banking:Product Analysis"} },
  • 16. Industry Models Glossaries • Each Industry glossary could be defined within its own namespace • Would probably settle on one json-ld per industry/namespace • For example: • im-banking: • im-insurance: • im-healthcare: • im-energy: • Each namespace represents a separate glossary/vocabulary
  • 17. GS1 glossary definition - useful section but rellies on too many namespaces just for definition of the glossary object - might be necessary to include it all in similar fassion { "@id": "gs1:", "@type": [ "voaf:Vocabulary", "owl:Ontology" ], "schema:license": "data:text/html;charset=UTF- 8,<p>GS1&reg;, under its IP Policy, seeks to avoid uncertainty regarding intellectual property claims by requiring the participants in the Work Groups that developed this vocabulary to agree to grant to GS1 members a royalty-free licence or a RAND licence to Necessary Claims, as that term is defined in the GS1 IP Policy. Furthermore, attention is drawn to the possibility that an implementation of one or more features of this vocabulary may be the subject of a patent or other intellectual property right that does not involve a Necessary Claim. Any such patent or other intellectual property right is not subject to the licencing obligations of GS1. Moreover, the agreement to grant licences provided under the GS1 IP Policy does not include IP rights and any claims of third parties who were not participants in the Work Groups. Accordingly, GS1 recommends that any organisation developing an implementation designed to be in conformance with this vocabulary should determine whether there are any patents that may encompass a specific implementation that the organisation is developing in compliance with the vocabulary and whether a licence under a patent or other intellectual property right is needed. Such a determination of a need for licencing should be made in view of the details of the specific system designed by the organisation in consultation with their own patent counsel. THIS DOCUMENT IS PROVIDED &quot;AS IS&quot; WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGMENT, FITNESS FOR PARTICULAR PURPOSE, OR ANY WARRANTY OTHER WISE ARISING OUT OF THIS SPECIFICATION. GS1 disclaims all liability for any damages arising from use or misuse of this vocabulary, whether special, indirect, consequential, or compensatory damages, and including liability for infringement of any intellectual property rights, relating to use of information in or reliance upon this document. GS1 retains the right to make changes to this vocabulary at any time, without notice. GS1 makes no warranty for the use of this vocabulary and assumes no responsibility for any errors which may appear in the vocabulary, nor does it make a commitment to update the information contained herein. GS1 and the GS1 logo are registered trademarks of GS1 AISBL.</p><p>Copyright 2015-2019 GS1 AISBL</p><p>Licensed under the Apache License, Version 2.0 (the &quot;License&quot;); you may not use this file except in compliance with the License. You may obtain a copy of the License at <a href=&quot;http://www.apache.org/licenses/LICENSE- 2.0&quot; target=&quot;blank&quot;>http://www.apache.org/licenses /LICENSE-2.0</a>.<p><p>Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an &quot;AS IS&quot; BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.</p>", "dc:contributors": "Eric Kauz, Mark Harrison, Phil Archer", "dc:creator": { "@id": "https://www.gs1.org/" }, "dc:description:": { "@language": "en", "@value": "The GS1 RDF vocabulary, described using W3C RDF Schema and the Web Ontology Language. The vocabulary builds on and refers to schema.org where appropriate." }, "dc:identifier:": "GS1 Vocabulary", "dc11:title": "GS1 Vocabulary", "dc:issued:": { "@type": "xsd:date", "@value": "2017-11-20" }, "dc:lastModified": { "@type": "xsd:date", "@value": "2019-12-01" }, "owl:versionInfo": "1.2", "vann:preferredNamespacePrefix": "gs1", "vann:preferredNamespaceUri": { "@id": "gs1:" }, "voaf:extends": { "@id": "schema:" }, "voaf:hasEquivalencesWith": { "@id": "schema:" }, "voaf:specializes": { "@id": "schema:" } }
  • 18. RDF & OWL overview diagrams https://www.infowebml.ws/rdf-owl/graphical-representations.htm