OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dita] DITA 2.0 enhancement: RDFa support


Hi Scott,

 

I’m glad you brought this up. I’m aware of the recent listening session feedback, and indeed for some time I’ve been meaning to suggest metadata enhancements along these lines. I’ve done quite a bit of work with clients using external taxonomy management and semantic tools alongside DITA, and it’s never easy. In my talk at DITA NA 2017, I went through some pros and cons of the current pure-DITA options. Every solution is slightly different and there is little standardization, even in the use of Subject Scheme. (Here are the slides, which include a matrix of what I classed and must-have and nice-to-have aspects of semantic metadata in DITA: https://www.slideshare.net/joepairman/taxonomy-now-building-a-stressresistant-knowledge-architecture-in-your-current-tools .)

 

It’s clear to me and a number of others that attributes are the way to go. As you say, they work well for inline metadata (far better than the counterintuitive use of nested <data> elements). Regarding RDFa in particular, I’ve been talking about using it with structured content for a while (https://joepairman.com/posts/is-structured-content-missing-a-trick ) and indeed used it for a recent DITA > Schema.org transformation (near the end of this deck: http://blogs.adobe.com/techcomm/files/2017/10/6-Give-Your-DITA-Wings-with-Taxonomy-and-Modern-Web-Design.pdf ). So you might think I’d be wholeheartedly in favor of getting it into the DITA 2.0 standard. I do think it’s probably a good idea but I want to raise some of the adoption challenges that I think it would face.

 

One of the issues with subject scheme (apart from the overloading of the key mechanism) is that every vendor implements it slightly differently. It’s quite understandable that the standard leaves implementations quite open, but on the other hand quite a few organizations I talk to feel that the existing guidance is not quite enough to get started. The range of vendor interpretations reflects this ambiguity. I’m not sure that the situation would improve with RDFa, indeed as RDF is a very open data model in terms of what it’s used for and what you say with it, new adopters might find it more difficult to get started. Of course if it were possible to provide some solid guidance on best practices, for example how to referr to SKOS concept URIs or RDFS classes, that would go a long way to resolving this concern.

 

Another potential difficulty is that RDFa has not been terribly popular, in part because it’s actually quite hard to implement well. One of the things that throws people off is that it’s overlaying a graph model on top of the XML tree, and what looks like a relation created by the tree often does not parse correctly into RDF. This is probably one of the reasons that JSON-LD Is overtaking RDFa and Microdata for serializing Schema.org (metadata primarily for search engines).

 

Finally, in semantic web (hence RDF) circles there is a growing tendency to store metadata separately from content, so for example each relevant element having a URI and the triples mentioning that element content all being stored as graph data in a graph database. Where and when that makes sense depends on a lot of things, but I just wanted to raise this trend or preference as another factor in deciding how much metadata should live directly within the content.

 

So to sum up, I think adding RDFa probably makes sense, but simply adding it won’t be enough to get it used in a consistent way. There would need to be good examples both in the spec itself (along the lines of the other excellent examples for things like troubleshooting), and also in supporting content. Those examples should have a clear scope and not be too ambitious — the RDF principle of “anyone can say anything about anything” is not terribly helpful to people who just wanted to link their taxonomy to their content in a reasonably interoperable way. I’m certainly willing to help with this effort!

 

Joe

 

Joe Pairman | Mekon | Tel: +44-7739-522002 | Mobile: +44-7472-745-063​ | Skype: joepairman

 

From: <dita@lists.oasis-open.org> on behalf of Scott Hudson <scott.hudson@jeppesen.com>
Date: Monday, October 23, 2017 at 19:22
To: "dita@lists.oasis-open.org" <dita@lists.oasis-open.org>
Subject: [dita] DITA 2.0 enhancement: RDFa support

 

Based on some of the feedback from the DITA Listening Sessions hosted by the DITA Adoption TC, I'd like to propose that we add support for RDFa to DITA 2.0.

 

For more information on RDFa, see https://rdfa.info/ and https://www.w3.org/TR/rdfa-lite/

 

Also, DocBook has added support for RDFa, so we could leverage some of the existing schema constructs to support this?

http://tdg.docbook.org/tdg/5.1/ref-elements.html

https://gist.github.com/docbook/2768701

 

Not only could this support better inline metadata, but also better support for classification of assets and possible replacement for subjectScheme.

 

Thanks and best regards,

 

--Scott

 

Voting member:

Boeing Data Standards Technical Advisory Board

OASIS DocBook TC, Publishers SC (Chair)

OASIS DITA TC, Tech Comm SC, LW DITA SC, Learning Content SC (Secretary)

OASIS DITA Adoption TC

OASIS Augmented Reality in Information Products (ARIP) TC

 

Scott Hudson
Content Strategist, Digital Aviation Learning and Development

Jeppesen, A Boeing Company

55 Inverness Drive East

Englewood, CO  80112

303-328-6228 | Cell: 303-350-7934

 

 

This document contains only administrative, uncontrolled data under U.S. International Traffic in Arms Regulations.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]