News & Blogs
S1000D RDF & Dublin Core Metadata
- Thursday, 14th September 2022
In the S1000D specification, you will find very little information about the Resource Description Framework (RDF) and Dublin Core (DC) and even less on how they are used.
Click image to enlarge
S1000D 4.1 Data Module viewed in Notepad++
So, to try and put a bit of meat on the bones of what we find in S1000D 4.1 Chap 7.4.1.1.2 ...
Structure within structure!
In web-oriented documents, RDF provides "structure" and Dublin Core provides "meaning" but, isn’t S1000D already about structured markup languages (SGML & XML) so why do we need structure within structure?
Yes, SGML & XML are both structured markup languages but let us not forget the big element and attribute name change between Issues 3.0 and Issue 4.0.
Click image to enlarge
S1000D 3.0 Data Module
S1000D 4.0 Data Module
Everything up to and including Issue 3.0 uses the abbreviated naming convention (e.g. <idstatus>) while Issue 4.0 and above uses the more detailed naming convention (e.g. <identAndStatusSection>).
This means that when you look at these two data modules, you will notice the only structurally consistent data is the RDF/Dublin Core metadata.
Hopefully that makes sense of the structure within structure issue so now ... what’s it for?
What’s it for?
We include metadata in web-oriented documents to make them "sharable".
The best example of this online "sharing" is when you create a post in a tool like LinkedIn. If that post includes a link to your website then you have just "shared" your website with the LinkedIn community and as long as your site has the right metadata in place then LinkedIn will convert the link into a "rich" link. LinkedIn knows what image to display and what text to output because it gets that information from the metadata so it enhances the post by using a "rich" link.
Click image to enlarge
A "rich" link block highlighted in a LinkedIn post
Linkedin provides the following article to help users "share" their content on LinkedIn:
Types of metadata
Unfortunately, not everybody uses the same metadata. If you follow the link to our www.docuneering.com website and take a look at the structured HTML source behind, you will see we use the following metadata types:
Click image to enlarge
Docuneering.com
Docuneering.com - View page source
S1000D Usage
A simple use-case we can think of is in the Table of References. Yes, the Author, as well as entering the Data Module Code, could also enter the <techName> and <infoName> but equally, the IETP code could easily use the target Data Module and the RDF/Dublin Core <dc:title> metadata to programmatically include the <techName> and <infoName>.
Also, in the body of a Data Module, that same RDF/Dublin Core lookup mechanism could be used to provide the <techName> and <infoName> as "tooltip" text whenever it finds a <dmRef> element (example: DMC-BRAKE-AAA-DA1-00-00-00AA-041A-A).
We would be interested to know if anyone is actually using the RDF/Dublin Core metadata either online or internally within an IETP. So please...
News & Blogs menu
Latest News & Blogs
2024
2023
- S1000D_Lite BREX Validation
- S1000D_Lite i18n Support
- Arbortext S1000D Authoring
- S1000D Front Matter Demo
- S1000D Stylesheet Support
- BREX & CALS Table Validation
- Cyber Essentials Certified
2022
- ATA CMP Print & Publish
- XSL Compiled Stylesheet
- Arbortext Editor Authoring
- S1000D Print Integration
- S1000D RDF & Dublin Core
- S1000D Common Stylesheets
- ATA CMP Para Numbering
- ATA CMP BREX Validation
- ATA Spec 1000BR CMP
- Xignal - S1000D in the Cloud
- Apache FOP v2.7 Release
- S1000D BREX Checker
- S1000D BRDP's
2021
- S1000D DM to PDF Overview
- Website HTML Validation
- S1000D Text Direction rl-tb
- S1000D Publishing Solutions
- S1000D Dev Sneak Peek
- S1000D DM to PDF German
- Thinking beyond the spec
- Oxygen S1000D Framework
- ISO 8879:1986 Compliant Font
- Validate PDF/A with veraPDF
- PDF/A Long Term Preservation
- S1000D Multiple Languages
- XML Character Entities
- S1000D DM to PDF (Demo)