Integrating RDFa With DITA, Metadata Improvements In General

[Eliot Kimber <ekimber@contrext.com>]

There seem to be two issues here:

1. The specifics of integrating RDFa with DITA in some way
2. The larger issue of “make DITA’s metadata story better”, whatever that might mean.

On the specific issue of integrating RDFa, as I said on the phone, there’s no barrier to doing that today, either through attribute specializations or through <data> specializations.

I heard the response that “people want it to already be there”. 

This is the meta issue: there are lots of specific solutions that communities need and that individual users or organizations shouldn’t have to invent for themselves. However it is not practical, realistic, or appropriate for the main DITA specification to provide these types of solutions. We’ve already seen the problems that causes with real and perceived increases in complexity. 

Going forward, the TC must focus on architectural issues, things that can only be done by extending or modifying the current architecture and base elements. All specializations should be pushed into subcommittees or non-OASIS activities.

DITA was designed from the beginning to allow controlled extension specifically so that these sorts of requirements could be met by the people or organizations that need them, without the need to standardize everything. 

I feel strongly that we should view the current L&T approach as a model: if you need something that is sufficiently general to warrant OASIS standardization then form a subcommittee and produce your specializations as separate deliverables. We’ve established that these efforts do not need to be synchronized with the main DITA standard.  

We need to do a better job of socializing the DITA community to take responsibility for its own needs, whether that’s through OASIS or through community-driven projects. 

I created the DITA Community organization on GitHub specifically to be a place to host these kinds of projects and OASIS provides another good place to host non-standard but standard-related projects.

We (the DITA and DITA Adoption TCs) have no funding. We have limited resources at the best of times. It will take all of those resources to see LwDITA out the door and produce something for DITA 2.0 before the end of the decade.

Another model would be IIRDS—if the IIRDS community wants to integrate with DITA then they need to provide the specializations and processing for it. Parsons has already started on this activity, as reported at DITA Europe.

The potential scope of metadata specializations is unbounded—every industry has its own metadata standards, approaches, technologies, and so forth. Every enterprise has its own local requirements. There’s no way we could address all of these in the context of the core DITA spec.

The current DITA metadata facilities are sufficiently general that they can be adapted to any metadata requirement one way or another. 

They are not perfect—that’s something we can and should address in DITA 2.x, but that’s an architecture-level activity to ensure that everything needed to support metadata specialization is provided for. For example, Parson’s observed that the inability to put <data> elements in some contexts, such as within table rows, limits the utility of <data> specializations, while attributes are truly universal. That’s something to think about for DITA 2.x. Likewise, the current requirement that each specialized attribute go in a separate module is annoying when you’re defining a whole set of attributes that all go together.

In any case, doing a literal inclusion of RDFa attributes into the DITA base architecture as was done in DocBook is not something I could ever support. It makes sense in DocBook because DocBook is a non-extensible monolithic vocabulary. There is no user name space in DocBook. But DITA is extensible and thus, like XML itself, must avoid taking names away from users as much as possible.

At a minimum, the attributes would need to have a distinguishing name prefix that clearly associates them with RDFa, otherwise we intrude too much into users’ name spaces. A name like “property” is simply too general to be allowable at the level of generality that the core DITA spec must reflect. A name like “rdfa_property” or “rdfaProperty” would be perfectly appropriate.

But that’s also a trivial specialization to define and implement. Somebody could code that over a weekend and implement processing support in the OT in another weekend. So why haven’t they? Why isn’t there already an RDFa plugin on DITA Community?

Cheers,

E.
--
Eliot Kimber
http://contrext.com