RE: [dita] Integrating RDFa With DITA, Metadata Improvements In General

["Jim Tivy" <jimt@bluestream.com>]

Hi Folks

Thanks for the well written description Joe.
It would be good to have a set of use cases to drive technology selection.
I think we need use cases and then decide the best technology for those use cases.  as well this will allow others to participate more.
As well, for which use cases are existing DITA technologies like topicmeta, indexterm and subjectScheme failing us?

Also, related, a major theme at Lavacon this year - microcontent.  Is one of our use cases the marking up of microcontent?

Jim


> -----Original Message-----
> From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf Of
> Joe Pairman
> Sent: November-14-17 7:20 AM
> To: Eliot Kimber <ekimber@contrext.com>; dita <dita@lists.oasis-open.org>
> Subject: Re: [dita] Integrating RDFa With DITA, Metadata Improvements In
> General
> 
> I’ve been thinking more about Scott’s suggestion and Eliot’s reply in the light of
> various discussions with Parsons, other active speakers on DITA/metadata, and
> recent projects.
> 
> I’d like to point out that it is actually not that easy for DITA users or tool vendors
> to work with metadata at the moment, at least not in a way that’s non-
> proprietary, generally applicable, and affordable. There are two aspects which
> are particularly hard in non-specialized DITA 1.3:
> - Annotating elements in a way that works well both in a pure DITA kind of
> environment, (e.g. authoring tools that control values based on Subject Scheme),
> and a mixed environment where annotation is assisted by external taxonomy
> management tools, particularly with relation to other standards such as SKOS.
> Of the two main modeling approaches, nested <data> *elements* are a real
> pain to work with in most authoring tools, but the most likely *attributes* do
> not accept full URIs.
> - Controlling metadata values at a topic or map level using prolog elements,
> again in a standards-compatible way that nonetheless remains usable for
> authors.
> 
> Of these two aspects, inline annotation is the most important to fix, I’d say. At
> the topic and whole-map level, various CMSs have proprietary ways of working
> with metadata whose ease of use arguably outweighs the problem of reliably
> exporting or migrating the content. But at the inline level, unless we get into Ted
> Nelson-style separate layers for content, semantics, and formatting, we have to
> store the metadata in the XML.
> 
> It is not easy for tool vendors to develop usable solutions to these problems,
> partly because the architecture itself makes it tricky, and partly because there is
> no clear guidance on what they should be doing. The solutions that do exist are
> incompatible and in some cases feel like workarounds for gaps in the
> architecture.
> 
> To the argument that any metadata extensions should be specializations rather
> than core, I understand and empathize, but I think the horse has already bolted.
> There is already a lot of specific guidance and out-of-the-box domain-specific
> markup in the standard, including of course the existing metadata elements
> (which don’t really seem to map directly to any external metadata standard).
> And of course there’s technical content: unless those specializations are
> detached from the standard as such, and the associated guidance on things like
> troubleshooting and domain-specific inlines also removed, users’ expectation
> will be that the whole of the standard contains guidance to about that level.
> 
> In an ideal world, specialization would be far more common and easier, and the
> kind of extension exchange culture that exists in other open initiatives would
> have taken root in the DITA community. Unfortunately, that hasn’t been the
> case yet, and if we relegate such core functionality as metadata support to what
> many people see as a rather tricky or even risky mechanism, we encourage the
> spread of even more incompatible workarounds.
> 
> Reflecting on Scott and Eliot’s emails, I can identify a middle-way approach:
> - Include out-of-box support for RDFa lite (not full RDF) in DITA 2.0, using the
> kind of prefixes that Eliot felt were advisable: “rdfaProperty” and so on.
> - Work with the people using iiRDS and SKOS as well as tool vendors, to flesh out
> realistic ways to use that RDFa lite support. Include brief examples in the
> standard itself (just as there are already examples of most other features and
> elements), and also produce longer accounts such as committee notes or DITA
> Adoption committee white papers
> - Optionally, give some brief consideration to also supporting CURIE
> declarations to allow more compact and readable attribute values.
> 
> I understand that this would take effort, and every new feature adds complexity.
> If the main intention behind DITA 2.0 is to simply tidy some stuff up, then
> perhaps it would be better to not add any special metadata support (apart from
> the changes to attribute rules that will make specializations more flexible). But I
> do think that if we want to further popularize DITA’s potential to work with
> granular content in a semantically-rich way, we should consider making it easier
> to work with external metadata.
> 
> Cheers,
> Joe
> 
> —
> Joe Pairman | Mekon | Tel: +44-7739-522002 | Mobile: +44-7472-745-063​ |
> Skype: joepairman
> 
> On 2017-11-08, 16:21, "dita@lists.oasis-open.org on behalf of Eliot Kimber"
> <dita@lists.oasis-open.org on behalf of ekimber@contrext.com> wrote:
> 
>     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
> 
> 
> 
> 
> 
>     ---------------------------------------------------------------------
>     To unsubscribe from this mail list, you must leave the OASIS TC that
>     generates this mail.  Follow this link to all your TCs in OASIS at:
>     https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php
> 
>