Re: [docbook] RFE: RDFa in Docbook 5

[Joshua Wulf <jwulf@redhat.com>]

Jirka, thanks for your reply. I hadn't looked at microdata or microformats.

At the risk of sounding like a raving nutjob, I'll try to present a
succinct version of our use case.

As authors, when we construct a book we make decisions about:
 * what information to include
 * how to group information
 * the order in which to place information

Some decisions are non-arbitrary, in the sense that there is only one
clear "right choice". For example: in a guide for beginners we would
omit information that is clearly for advanced use cases. In an
"Administrators Guide" we would omit information that is only of
relevance to Developers.

Other decisions are arbitrary, in the sense that there exist more than
one possible "right way" to do it. For example: how we structure the
information in a book in terms of grouping, or in which particular
chapter we place some information that could arguably reside in any one
of several different places.

In the wider picture, we make assumptions about the audience, about
which concerns are logically grouped based on their work, or which
components of a large suite of technologies they interact with.

Topic-based authoring gives us the opportunity to build multiple output
constructs (books) from the same raw material - recombining the contents
according to different patterns that match to real-world use cases.

Beginners Guide for one component, Advanced Guide for one component,
Beginner to Advanced for this one component, Beginners Guide to the
whole suite, and any number of different combinations.

Topic-based authoring allows us to recombine the same material multiple
times at low cost.

For authors who construct deliverables from topics in this way, the
ability to locate topics based on aspects such as product, component,
audience, assumed knowledge, end-user concern, relationship to other
pieces of information, and other concern is crucial.

Encoding the information into the Docbook xml (or storing it in a
separate relationship database as we currently do) enables ordering,
grouping, and (arbitrary) relationship of data to enable discovery by
authors, and to encode "sense" into the data set.

When we make decisions about what information to include, we do it based
on a number of factors: what audience it is relevant to, the level of
assumed knowledge of the reader, the product and component that it
relates to, its relationship to other pieces of knowledge that are
dependencies, and so forth. When we make decisions about how to
structure that information in the output we do it based on other
factors, such as which is the dominant grouping concern and which the
secondary grouping concern and what is the logical sequencing concern to
use.

What if... we could encode that information in the built html?

In that case, as well as offering a set of predefined static narratives,
we could also offer the reader the ability to navigate the information
set along multiple potential pathways. In other words, the reader
participates in the creation of the narrative (in an assisted way), in
much the same way that an author would have created a "best guess" or
"one size fits all" narrative for them.

If a piece of information could potentially have been placed in several
different chapters in a book we can represent that in a way that makes
the information appear where the user is looking for it, whether they
are following a sequence through a continuous concern, a relationship
graph such as a process, a traversing grouping by discrete concerns.

It opens the door also to descriptive pathways and relationships,
generated from user behaviour, rather than just prescription by authors
and information architects.

It also opens the door to more targeted search, the opportunity for
external systems to discover, consume, and mashup our content, and even
the possibility of expert systems that could use our documentation to
answer user questions.

So we're looking for something to support development in that direction
- both to encode the metadata for our authors, to extend it to users for
a different narrative experience, in addition to expert-prescribed
narratives (books), and to make it available via (semantic) API to the
world. RDFa and SPARQL looked promising.

Right now we are basically at the "sideways table" stage of relationship
database management of the metadata described as the event horizon of
RDF. :-)

- Josh

On 12/13/2011 07:12 PM, Jirka Kosek wrote:
> On 13.12.2011 3:28, Joshua Wulf wrote:
> 
>> I'm not sure if I have it right, but it seems that Docbook 5 with its
>> xml schema base supports adding RDFa data to the xml with no problems.
>> What I'd like is to have that RDFa data flow through to the built html
>> output.
> 
> Hi Joshua,
> 
> could you elaborate more on you requirements. What's usecase for having
> RDFa in DocBook?
> 
>> I've opened the RFE against the XSL stylesheets rather than against the
>> DTD/schema because (I think) that's the only place that changes would
>> need to be made. Have I opened it in the right place?
> 
> Probably no. If we decide that adding RDFa into DocBook is good idea,
> schema has to be modified first. If you look at
> http://www.w3.org/TR/rdfa-syntax/ you will see that special atttributes
> like property, rel, about, resource, datatype are needed to convey RDFa.
> If you want to use RDFa in DocBook similar attributes has to be added
> into DocBook.
> 
> Once this is done, appropriate change in stylesheets has to be done as
> well to pipe these metadata to XHTML output.
> 
> But it would be really interesting to know what problem are you trying
> to solve. Honestly, future for RDFa doesn't look very bright IMHO.
> Currently it can be used only in XHTML, not in HTML. It seems that
> approach chosen by microdata/schema.org has more chances on the market.
> But we will see.
> 
> 					Jirka