Support for Multiple Formats

[AdamSobieski]

Inspired by content negotiation, multipart MIME, and MathML's <annotation> and <annotation-xml> elements, we can, instead of necessitating that content authors commit to one format for portions of content, provide the expressiveness for content authors to include content in multiple formats simultaneously.

<data type="multipart/alternative">
  <data type="text/n3">...</data>
  <data type="text/turtle">...</data>
</data>

Combining this idea with client-side preprocessing:

<data type="multipart/alternative">
  <data preprocess="text/php" type="text/n3">...</data>
  <data preprocess="text/php" type="text/turtle">...</data>
</data>

or

<data type="multipart/alternative">
  <data preprocess="text/php" type="text/n3">...</data>
  <data preprocess="text/gpp" type="text/n3">...</data>
</data>

Using this convention, the running example of defining a parametrically polymorphic type, widget<T>, might resemble:

<types>
  <type name="widget" uri="...">
    <parameters>
      <parameter name="T" uri="...">
        <!-- describe type parameter here -->
      </parameter>
    </parameters>
    <metadata>
      <data type="multipart/alternative">
        <data preprocess="text/php" type="text/n3">...</data>
        <data preprocess="text/php" type="text/turtle">...</data>
      </data>
    </metadata>
    <definition>
      <data type="multipart/alternative">
        <data preprocess="text/php" type="text/n3">...</data>
        <data preprocess="text/php" type="text/turtle">...</data>
      </data>
    </definition>
  </type>
</types>

In this way, deserializers could select from provided alternatives.

With respect to describing data alternatives, factors to consider include:

1. data format
2. preprocessing required
3. ontologies utilized
4. internationalization

With respect to making explicit the ontologies utilized in a data alternative, a space-delimited list of URI's could be provided for an ontologies attribute on <data> elements:

<types>
  <type name="widget" uri="...">
    <parameters>
      <parameter name="T" uri="...">
        <!-- describe type parameter here -->
      </parameter>
    </parameters>
    <metadata>
      <data type="multipart/alternative">
        <data type="text/n3" ontologies="ontology1 ontology2">...</data>
        <data type="text/n3" ontologies="ontology3 ontology4">...</data>
      </data>
    </metadata>
    <definition>
      <data type="text/n3">...</data>
    </definition>
  </type>
</types>

With respect to internationalization, could use the xml:lang or a lang attribute on <data> elements:

<types>
  <type name="widget" uri="...">
    <parameters>
      <parameter name="T" uri="...">
        <!-- describe type parameter here -->
      </parameter>
    </parameters>
    <metadata>
      <data type="multipart/alternative">
        <data preprocess="text/php" type="text/kif" lang="en">...</data>
        <data preprocess="text/php" type="text/kif" lang="fr">...</data>
      </data>
    </metadata>
    <definition>
      <data type="text/kif">...</data>
    </definition>
  </type>
</types>

Additionally, the language preferences of a client could be among those data available to client-side preprocessing scripting languages.

[AdamSobieski]

Also, brainstorming, yet more expressive and extensible possibilities for describing data alternatives include providing a means of attaching arbitrary metadata to each data alternative, e.g., fully-fledged semantic metadata. Metadata describing data alternatives would then be more expressive than those attributes considered above for the <data> element (type, preprocess, ontologies, lang).

<data uri="...">
  <about type="text/n3"><!CDATA[[ ... ]]></about>
  <content><!CDATA[[ ... ]]></content>
</data>

In this example, the contents of the <about> element would provide extensible metadata about the contents of the <content> element.

Also possible is that the actual content for the data alternative could be stored in a string or XML literal in the semantic data.

<data uri="...">
  <about type="text/n3"><!CDATA[[ ... ]]></about>
</data>

or retrieved from a specified location.

<data uri="..." src="...">
  <about type="text/n3"><!CDATA[[ ... ]]></about>
</data>

In any event, it should be possible to provide expressiveness for describing multiple data alternatives for each property of each element of a planning domain, these elements including: types, objects, predicates, assertions, operators/actions, constraints, and preferences.