Re: [RIF] Extensible Design: Horn semantics and syntax actionscompleted

On Tue, 2006-10-03 at 16:50 +0200, Christian de Sainte Marie wrote:
> Boley, Harold wrote:
> > 
> > I don't remember any extended discussion of language information.
> > Regarding the XML syntax, I think for such purposes we could reuse
> > the existing attributes from relevant W3C specs within the <Data>
> > element.
> 
> Dan, could you outline an use case for language information?

I won't argue that there should be special abstract syntax for
language information. I think that's a terrible, terrible design
bug in RDF 1.0. A lang("dog", "en") function symbol should
do fine, where lang has a standardized URI.

But aside from details of how it fits into the abstract syntax,
the use cases for language information are pervasive, no?
i.e. everywhere that human language text is allowed,
language information is needed:

[[

2.  Where to do internationalization

   Internationalization is for humans. This means that protocols are not
   subject to internationalization; text strings are. Where protocol
   elements look like text tokens, such as in many IETF application
   layer protocols, protocols MUST specify which parts are protocol and
   which are text.
]]
 -- http://www.ietf.org/rfc/rfc2277.txt
  <- http://www.w3.org/TR/2005/REC-charmod-20050215/

Unlike most W3C WGs, I see RIF doesn't have an explicit liaison
to the I18N WG. But I do see one to the XML Schema and Query WGS...
  http://www.w3.org/2005/rules/wg/charter#w3c-xml

... and when those WGs review specs, they're quite sensitive
to  I18N issues.


> > [...]
> > 
> > Allowing <Atom> outside an Implies (e.g., directly in a Rulebase)
> > is what we intended.
> 
> You mean, as a fact?
> 
> I would prefer (see [1]) that the XML syntax of a rule something like
> <Rule>
>    <RuleVariables>

As far as I'm concerned, the XML concrete syntax is mostly a collection
of coin flips. Anything that maps relatively cleanly to the abstract
syntax in the current design proposal is OK by me.

One possibility that seems very interesting, to me, is to use
MathML as the concrete syntax. I have been playing with it for a while;
Back in November 2004, I had the definitions in the SPARQL spec
(not the complicated optional and BOUND and stuff) transcribed
in MathML and converted to N3, and I was able to get cwm to pass
one SPARQL test by executing the resulting rules.
http://www.w3.org/2001/sw/DataAccess/mathml-rules.xml

Just the other day I started adding to n3absyn.py support for
converting the other way, i.e. from N3 rules to MathML.
I think there are still some kinks to work out, but it's
a fun idea to play with.

http://www.w3.org/2000/10/swap/n3absyn.py


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Tuesday, 3 October 2006 15:52:16 UTC