Re: RDFa Core Review: Host Language conformance

Hi Jeni, hi all,

2011-01-05 18:40 Jeni Tennison:
> I'd like to see it:
>
>   1. explain more specifically what "the facilities required in this specification" (mentioned in the first bullet point) actually are
>   2. say that any extra Host Language-specific processing rules MUST result in a superset of the triples produced by the RDFa Core processing rules
>   3. say that Host Language specifications MAY specify an initial list of *term mappings* and SHOULD do so through a profile
>   4. say that Host Language specifications MAY specify a *default vocabulary* and SHOULD do so through a profile
>
> I think it should also say something along the lines of:
>
>   "Host Languages MAY define extra processing that creates additional triples in the *default graph*, but MUST NOT define extra processing that changes the triples that core processing creates."

From the point of view of another host language (see details below), I
must say that I'm not quite sure how restrictive the RDFa Core spec
should be in this regard.  Being as restrictive as you suggest will
probably be of advantage for quite some "well-behaved" potential host
languages, whereas it would get some other languages into trouble.  The
OMDoc language for mathematical documents (http://www.omdoc.org), about
which I am concerned, is an example for the latter.  It is a semantic
markup language with a rich (from an RDFa point of view) "legacy"
semantic vocabulary, which leads to conflicts with the RDFa semantics.
In short:

1. A specification of OMDoc+RDFa that conforms to RDFa Core is feasible.
 However, it requires some changes to the legacy OMDoc syntax.  (In
short: OMDoc already had a different way of giving URIs to things, and
annotating things with a restricted vocabulary of metadata, and an
unofficial translation of all that to RDF.)
2. Most OMDoc users don't care about non-mathematical metadata (which is
what RDFa is needed for in OMDoc) and are not willing to use a new,
RDFa-conforming syntax.

For details, see my Ph.D. thesis draft at
https://svn.kwarc.info/repos/swim/doc/phd/phd.pdf, chapter 5.  This will
soon become part of the OMDoc 1.3 specification.  This also contains
concrete examples for (1) and (2).

(1) is done.  The (small) user community will require (2) as well, or,
if I don't officially provide (2), they will ignore (1).

I see two possibilities for such cases:

a. Have a liberal RDFa spec, which allows languages with legacy semantic
markup that potentially conflicts with RDFa Core to be extended by RDFa
in a conforming way – at the expense of making it impossible to
implement general RDFa parsers, as such host languages will require
custom processing rules that can't be expressed in a generally
machine-comprehensible way.  Then, I could declare OMDoc+RDFa as
compliant with RDFa Core, both in its syntactic variant (1) and (2).
b. Have a restrictive RDFa spec, which disrupts the evolution of some
future host languages, whose semantic markup conflicts with RDFa.  In
the OMDoc case, (2) would be specified as a non-RDFa-conforming syntax,
with a translation to the more elaborate syntax (1), which conforms to
RDFa Core, and we would provide a tool that performs this translation.

Both (a) and (b) would be fine with me.  Do you have any opinions on that?

Note, once more, that OMDoc is just a representative for languages with
a rich semantic (and URI-aware) vocabulary that has been developed
before RDFa.

Cheers,

Christoph

-- 
Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype
duke4701