From: Harold Boley (boley@informatik.uni-kl.de)
Date: 11/09/02
Sandro, > (Harold, you mentioned that you had replied to my message from last > week about coming up with a single unified XML & RDF/XML syntax, but I > haven't seen it. It is perhaps superceded by last night's discussion > and this message.) I guess you mean this message you sent to Benjamin and I on 30 Oct 2002: > ... continuing up on my comment on the phone yesterday, during the JC > meeting. > > My thought is this: you may be able to pick a syntax which is both > valid RDF/XML and not too ugly for normal XML use. Mostly this > involves throwing in some rdf:parsetype attributes. It's a kind of > middle ground which RSS and some other standards flirting with XML and > RDF try. The RDF folks like having RDF, but they have to stick to > one exact form of it. The XML folks like having XML, but they have to > put in these weird & silly attributes sometimes. > > It's hard for me to be more precise without examples, and I'm not sure > which examples would be the best ones. > > (This is odd -- usually I'm the guy arguing you should just have > multiple concrete syntaxes for one abstract syntax.) I mentioned on 5 Nov 2002 that I'll come back to your email once I had a chance to better understand rdf:parsetype. After looking into previous rdf:parsetype uses I now think this could well be some parallel effort but hardly replace the wide-spread XML syntax. The RuleML 0.8 XML syntax, which integrates the XML and RDF data models (http://www.dfki.uni-kl.de/~boley/xmlrdf.html), is useful as the source from which a pure-RDF RuleML syntax can be generated -- in the tradition of our XSLT-based translator from the pure-XML RuleML 0.7 to a pure-RDF RuleML (http://www.dfki.uni-kl.de/ruleml/inrdf.html). The slides "RuleML Meets RDF" (http://www.ruleml.org/rdf/ruleml-rdf.ppt, 12 Nov 2002: http://www.ruleml.org/rdf/ruleml-rdf.pdf) contain examples of the XML-RDF-integrating RuleML 0.8 and of a pure RDF RuleML. > Thanks for the presentation yesterday. I had to leave about 5:05 > EST, before the meeting actually ended. I imagine I missed the most > interesting comments; were any decisions made? No, but very valuable feedback was obtained from several JC members. > Despite my experience doing very similar work, I'm still impressed by > how tedious both the XML and the RDF/XML serialization are. I had to > remind myself that this is like looking at the assembly-language > output of a compiler: it's important to get right, and then no one but > tool-builders should ever have to see it again. Well, the markup provides extra information about the syntactic categories of logic (sub)formulas (e.g., RuleML's *type* of an atom for atomic formulas) and their unordered-labeled or ordered-unlabeled occurrences in superformulas (e.g., RuleML's unordered-labeled *role* of a _head for formulas occurring as conclusions). The markup thus serializes *syntax trees*, which for RuleML 0.8 are actually *abstract* syntax trees with RDF-property-like role labels as selectors and XML-child/RDF-Seq-like ordered branches as tuple constructors. Besides the 'discount' example in the slides, let's look at the 'own'-rule variations at http://www.ruleml.org/indtd0.8.html#Context : * The variation T6/X6, closest to a pure-RDF RuleML syntax, is indeed a bit lengthy, but its RDF Seq containers confine XML-like positional (ordered) children to the minimum. (Similarly, T7/X7 uses a tup type to put an n-ary argument sequence into a single argument, which is legal in RuleML 0.8.) * The variation T1/X1 corresponds to the pure-XML RuleML 0.7. * The variation T3/X3 corresponds to RuleML 0.8, which employs RDF-like role labels exactly where they prevent order overspecification (which arbitrarily puts a non-positional type into the child order) and uses the natural XML child order instead of RDF's Seq containers. > With that in mind, maybe using a single, canonical RDF/XML > serialization, no matter how hideous it's likely to be, would be > best. See above. > (I'm imagining an RDF/XML serialization which is constrained > to specific choices about use of type-nodes, etc, so that it's > amenable to processing by XSLT and other non-RDF tools. I assume > that's important to your user base.) (Such constraints may be hard to maintain across all intermediate tools that are involved in rule exchange, so that XSLT-like processing -- central to RuleML's canonical-language mission -- may become quite difficult.) > I'd love to see you follow the convention of uppercase names for > classes and lowercase names for predicates; I find it makes the > striped syntax much more readable. This has been used in RDF RuleML. Since the case-dependent interpretation of file names across operating systems and/or for variable names across programming languages has been a frequent source of errors, we introduced another convention for the distinction of types and roles in the XML-RDF- integrating RuleML. > You seem to be trying to have the > RDF/XML syntax look like the XML syntax with a few added bits; I don't > see much reason for that; either think in XML or think in > graph-syntax. In the markup it is this 'bit': Tag name *without* an underscore prefix, e.g. atom: Type Tag name *with* an underscore prefix, e.g. _head: Role In the abstract syntax trees it is: Node label: Type Arc label: Role > Can we get rid of ruleml:cdata, and just map the non-RDF RuleML > identifiers into RDF identifiers? In your slide 11 ("striped > serialization"), instead of > <rel ruleml:cdata="discount"/> > one could use > <rel href="&someNameapce;discount"/> RuleML's names for (variables, individual constants, ..., and) relations like discount sit directly below a type such as (var, ind, ..., and) rel. The corresponding literals in RDF are, however, reached by a property/role. The attribute ruleml:cdata is just to move a name from the former to the latter position. We had earlier called it ruleml:name. Any better proposal is very welcome. > This does require the "ur" logics to be understood, though; perhaps > that's an unacceptable burden. Some provision (probably using > %-escaping) would also be needed for non-URI-char names). As I mentioned in the telecon, the attribute href is currently used to refer to any resource, unspecifically, while rdf:resource was proposed to refer to an RDFS class. This is very preliminary. In the telecon, Peter and Pat proposed that some ruleml:attribute be used instead of rdf:resource; for Ora rdf:resource seemed OK, unless it parses as RDF. > My big question (was this addressed after I left?) is Benjamin's > original one: is RuleML the right starting point for RDF Rules (aka > DAML Rules)? Personally, I'm waffling over whether its additional > complexity is desirable or not. It's hard to know. As discussed above, RuleML's markup / abstract syntax trees provide extra information about syntactic categories. If you don't want to see this and don't need to be in XML, use a compact concrete syntax such as pure Prolog or N3. > A simpler approach might be something like having XML tags <Rule>, > <if>, and <then>, and inside the "if" and "then" clauses one can put > arbitrary RDF/XML (aka DAML). Actually, we started in such a top-down fashion to also permit semiformal rules (http://www.ruleml.org/insteps.html#Example-RuleML). > There would also need to be a way to > mark variables, and to convince people it's okay to use RDF/XML in > this quoted (not asserted) manner. TimBL suggested parsetype="quote" > for this, which would the whole thing RDF again, except for indicating > variables. (In this case, we need to indicate both existential > variables and universal variables if we want Horn expressivity; we > have no functions, but we can de-Skolemize the functions into > expressions using existentials scoped to the consequent.) Perhaps we could collaborate on aligning use cases in RuleML, DAML+OIL, and OWL as well as in N3 and this 'parsetype-RDF' to see where possible advantages and limitations of each of these approaches may be? Similarly, tools such as rule editors, translators, and engines could be compared. Harold
This archive was generated by hypermail 2.1.4 : 11/09/02 EST