Ian --<br><br>There's an authoring and reasoning tool that you may like to evaluate for your purposes.<br><br>A possible advantage of the tool for your tasks is that it explains its answers, step by step, in hypertexted English.<br>
<br>The vocabulary for writing rules in executable English is open, but the tool can reason about controlled vocabularies, inheritance, and so on.  It covers some examples that are not do-able in OWL.<br><br>The tool is online at the site below.<br>
<br>Apologies if you have seen this before, and thanks for comments.<br><br>                                                    -- Adrian<br>                   <br>Internet Business Logic<br>A Wiki and SOA Endpoint for Executable Open Vocabulary English over SQL and RDF<br>
Online at <a href="http://www.reengineeringllc.com">www.reengineeringllc.com</a>    Shared use is free<br><br>Adrian Walker<br>Reengineering<br><br><div class="gmail_quote">On Tue, May 19, 2009 at 9:36 PM, Ian Hickson <span dir="ltr"><ian@hixie.ch></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
One of the use cases I collected from the e-mails sent in over the past<br>
few months was the following:<br>
<br>
   USE CASE: It should be possible to write generalized validators and<br>
   authoring tools for the annotations described in the previous use case.<br>
<br>
   SCENARIOS:<br>
     * Mary would like to write a generalized software tool to help page<br>
       authors express micro-data. One of the features that she would like to<br>
       include is one that displays authoring information, such as vocabulary<br>
       term description, type information, range information, and other<br>
       vocabulary term attributes in-line so that authors have a better<br>
       understanding of the vocabularies that they're using.<br>
     * John would like to ensure that his indexing software only stores<br>
       type-valid data. Part of the mechanism that he uses to check the<br>
       incoming micro-data stream is type information that is embedded in the<br>
       vocabularies that he uses.<br>
     * Steve, would like to provide warnings to the authors that use his<br>
       vocabulary that certain vocabulary terms are experimental and may<br>
       never become stable.<br>
<br>
   REQUIREMENTS:<br>
     * There should be a definitive location for vocabularies.<br>
     * It should be possible for vocabularies to describe other vocabularies.<br>
     * Originating vocabulary documents should be discoverable.<br>
     * Machine-readable vocabulary information shouldn't be on a separate<br>
       page than the human-readable explanation.<br>
     * There must not be restrictions on the possible ways vocabularies can<br>
       be expressed (e.g. the way DTDs restricted possible grammars in SGML).<br>
     * Parsing rules should be unambiguous.<br>
     * Should not require changes to HTML5 parsing rules.<br>
<br>
<br>
I couldn't find a good solution to this problem.<br>
<br>
The obvious solution is to use a schema language, such as RDFS or OWL.<br>
Indeed, that's probably the only solution that I can recommend. However,<br>
as we discovered with HTML5, schema languages aren't expressive enough. I<br>
wouldn't be surprised to find that no existing schema could accurately<br>
describe the complete set of requirements that apply to the vCard, vEvent,<br>
and BibTeX vocabularies (though I haven't checked if this is the case).<br>
<br>
For any widely used vocabulary, I think the best solution will be<br>
hard-coded constraints and context-sensitive help systems, as we have for<br>
HTML5 validators and HTML editors.<br>
<br>
For other vocabularies, I recommend using RDFS and OWL, and having the<br>
tools support microdata as a serialisation of RDF. Microdata itself could<br>
probably be used to express the constraints, though possibly not directly<br>
in RDFS and OWL if these use features that microdata doesn't currently<br>
expose (like typed properties).<br>
<br>
Regarding some of the requirements, I actually disagree that they are<br>
desireable. For example, having a definitive location for vocabularies has<br>
been shown to be a bad idea for scalability, with the W3C experiencing<br>
huge download volume for certain schemas. Similarly, I don't think that<br>
the "turtles all the way down" approach of describing vocabularies using<br>
the same syntax as the definition is about (self-hosted schemas) is<br>
necessary or, frankly, particularly useful to the end-user (though it may<br>
have nice theoretical properties).<br>
<br>
<br>
In conclusion: I recommend using an existing RDF-based schema language in<br>
conjunction with the mapping of microdata to RDF. Implementation<br>
experience with how this actually works in practice in end-user schenarios<br>
would be very useful in determining if something more is needed here.<br>
<font color="#888888"><br>
--<br>
Ian Hickson               U+1047E                )\._.,--....,'``.    fL<br>
<a href="http://ln.hixie.ch/" target="_blank">http://ln.hixie.ch/</a>       U+263A                /,   _.. \   _\  ;`._ ,.<br>
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'<br>
</font></blockquote></div><br>