SW language compatibility breakout Evan Wallace scribing Starting 1:50 PM 9 November Sandro chairing Sandro: my question is whether OWL compatibility is going to really be hard or not. PPS: do we have any Herbrand imperialists here. Sandro: should we have two documents, one for each language Bijan and Evan: No. Bijan: Different sections are OK. What are the questions about phase I that effect compatibility. DF: Horn fragment. Most languages don't reason about Horn fragments. Bijan: interop doesn't necessarily mean a shared core. Bijan: A Hilog person might be looking for having access to RDF data or OWL ontologies. DF: Enumerate the possible ways of combining. Identifying a subfragment -vs- id'ing an interface between them. Bijan: All of these are ways of taking DL... PPS: there are diff ways of providing semantics for Horn clauses that matter in certain cases but not in others. Bijan: query language discussion: identical in grnd entailments but not all entailments Uli: several of these choices have already been described but they result in different consequences. Sandro: I m hoping that we can postpone the differences until phase II. PPS: The differences could be invisible from certain viewpoints. But some in this room are concerned about the viewpoints that expose these differences. Bijan: SPARQL is an issue. It is enough to expose the difference. Sandro: I need to see the details to understand the differences. I am not sure that SPARQL at that level. Bijan: if we don't address SPARQL compatibility then will have not addressed the issue of compat with relevant W3C stds which would be a dependency normally in a w3c grp. Df: describe the difference of the semantics in the interface to sparql for example. Bijan: We probably cannot defer the issue of semantic heterogeneity to phase II. We have discussed some approaches to this. Different operators, Global Flags (identifying the semantics), K operator, ... Jos: it is tricky though if you allow the mixing of these things (operator) PPS the tricky bit is combing things from different systems. The Chinese menu problem. Bijan: in interchange scenarios the global flags work. DF: Let's look at the givens with the sem web. Mixing is a fundamental sue case. Sandro: I worry about trying to sell this to the rest of the world. Uli: I understood that you wanted a single phase I semantics. Sandro: definitely. DF: even if you have a not in your query language you will run into the problem of different negation operators. DER: Do we have negation in SPARQL already? Bijan: It has existentials which gets you there. Discussion of allowing Bnodes in SPARQL queries. DER: we could define a fragment of SPARQL which avoids the problem, when it's used. DF: One approach: we don't specify the sem of the language but define it in terms of sparql. Sandro: we could pick one of the semantics in phase I with the assumption that we will allow more semantics later which could lead to these problems in interop. Sandro: I don't think that the users will want to see this. It will look like there is no real standard. Bijan: So? Uli: [Paraphrasing]: If we know that there is different semantics then we can identify the different assumption and answers that we will get and deal with them. Sandro: You aren't proposing to let a thousand languages bloom? Bijan: Why not? PPS: I am thinking of tagging with the semantics used, not the tool name/version. PPS: There is a fairly decent overview on this called "Deviant Logics" Sandro: I hear a consensus emerging that "We need a semantic extensibility point from the beginning and only two semantics for phase I." PPS/Bijan: one could identify inclusion relations for combinations. Bijan: Saying something like "import ALlog'ishly" [Paraphrasing]: Based on a survey of the languages and their semantics. We could define a set of apriori relation classes. Bijan: I doubt that we could rule this down to one subsuming all others. Der: we need to strive Discussion: a two bit flag is needed to cover intersection | union | ??. Uli: it would be better to have possibility too many and have one drop out from disuse then to have to redesign. Df: white box vs black box Sandro: [approaches to this work] We could have an OWL compatibility task force or we have editors who just talk to people or ... Consensus: create a task force but use the wg mailing list with a task force tag prefix in the subject line. Bijan: the charter is written so that we extend a language. An alternative is that we create the superset and subset it. Bijan: let me argue the meta-logical approach. We at least have a chance that our work is verifiable because we will capture it formally. Uli: I would then prefer to have some not so perfect extensions to overload (test) the kernel. This other thing: having some sort of description language to describe each language. pps: We are explicitly allowed to have a different external form that gets transformed before used. Tagging a set of rules may have some challenges. Bijan: sparql already has named graphs. Sandro: Can we talk about RDF? Jos: How do we have to interoperate with RDF? The question is how to consume it. Bijan: Different requirements: Be able to use RDF facts. Are RDF names syntactic carriers for our operators. N-ary predicate issue. der: is there a need for an export as well as an import capability? Sandro: some other ones are lists? How do list structures of these other languages map into the rdf lists. Then there are datatypes. Alternate concrete syntaxes discussion. Sandro: It is too soon to deprecate rdf/xml. Bijan: three possibility: encode all facts, or encode all rdf facts, Need literals as subjects. What is the possibility of getting this fixed in rdf/xml? Sandro: It depends on how objectionable the members find it. Can this group fix user defined datatypes? DF: integration with OWL is about integrating with DL whereas integration RDF is about integrating with the triple model. RDF points: syntax, n-ary and semantics der: people who work with RDF now, treat bnodes as names. But in other languages these are treated differently.