Re: Concrete Syntaxes

From: Harold Boley (
Date: 11/12/03

  • Next message: Benjamin Grosof: "Re: notes from 11/11/03 JC telecon on Rules and preparing W3 Note"
    Hi Mike,
    > > > I then propose to also keep our previous clear indication
    > > > for the RuleML namespace. Such multiple namespaces made the
    > > > OWL RuleML combination immediately possible: ruleml:imp, etc.
    > >
    > > The problem is that none of the ruleml: DTDs or XML Schemas
    > > know to expect classAtom, individualPropertyAtom, etc. as
    > > subelements - only swrl: will know about these.  This is
    > > somewhat analogous to swrlx:Ontology extending owlx:Ontology.
    The RuleML SC has anyway planned such a 'pluralism' on the atom level,
    and the corresponding XML Schemas could be modified by David Hirtle (Cc).
    > I think the underlying issue is that one can re-use elements
    > from other DTDs/schemas/namespaces as self-contained
    > subtrees within an XML tree (as we would for OWL class
    > definitions embedded within rules), but not for modified
    > interior elements.
    The interplay between XML Namespaces and XML Schema validators
    certainly deserves a closer look.
    > Note that such reuse is fine in RDF, because one could
    > define, for example, swrl:ClassAtom as a subclass of
    > ruleml:Atom.  Such extensibility is one of the advantages of
    > RDF.
    Closing off some description after it is finished may be hard though,
    as we discussed today (and desired only for defining syntactic
    and other 'closed' objects, but not desirable for Web metadata).
    > One could define another SWRL-specific RuleML
    > namespace and split the definitions between swrl: and
    > ruleml:, but that seems to overly-burden the user just to
    > achieve ancestral symmetry.
    > Another alternative is to always use a single swrl:
    > namespace, but I had been hoping to re-use the current owlx:
    > elements without having to specifically copy them.
    The possible need for copying may indeed be a drawback of a new
    namespace that 'overlaps' with existing ones.
    > I realize that I'm correlating namespaces with DTDs/Schemas,
    > etc. here, but that's because I feel it's essential that the
    > namespace URI be resolvable to a document that tools can use
    > to check content.
    I guess perfect schemas behind proposed namespaces are not a
    'must' for the first round. But let's work towards them.

    This archive was generated by hypermail 2.1.4 : 11/12/03 EST