The Abstract Syntax Mechanism ("The Triangle")

<DaveReynolds> Scribe: Dave Reynolds

<DaveReynolds> ScribeNick: DaveReynolds

Introduction session to F2F7

Objective of F2F is prepare next WD of BLD as early as poss in Oct in prep for next meeting in Boston

<ChrisW> I emailed around a seating chart for the meeting

Planned order of topics on agenda on: http://www.w3.org/2005/rules/wg/wiki/F2F7

First subsection: abstract syntax - BNF or ASN07?

<IgorMozetic> is there any dial-in?

Sandro: last fall proposed notion of abstract syntax, developed asn06, demonstrated mapping to OWL and XMLSchema
... Harold also wants a BNF style for the abstract syntax, also have UML diagram
... so have set of roughly equiv expressions for the abstract syntax, differnce is mostly editorial
... one difference noted is that AEBNF doesn't explicitly mark ordered, apart from that the syntaxes are equivalent

<AxelPolleres> main problems in asn/ebnf are IMO: order, cardinality/optional, etc.

csma: if they are indeed equivalent do we keep only one or do we have several with one normative?
... e.g. the AEBNF might be normative with the asn07 as informative because it is more readable

Sandro: would lean to only having the XML Schema as normative, all else informative

Jos: but the semantics ties to a specific syntax and so that syntax also has to be normative

Harold: the semantics is given in presentation syntax so need semantics-preserving xform from ps to xml syntax

csma: does the semantics need presentation syntax rather than abstract syntax?

Michael: order by akwardness - asn, abstract, presentation from hardest to easiest

csma: are we sure they are equivalent?

Sandro: no sure, believes so, nnott implemented converters for all cases

csma: don't need complete equivalence just that the specification of RIF is same in each case
... e.g. the AEBNF might be normative with the asn07 as informative because it is more readable

Sandro: would lean to only having the XML Schema as normative, all else informative

Jos: but the semantics ties to a specific syntax and so that syntax also has to be normative

Harold: the semantics is given in presentation syntax so need semantics-preserving xform from ps to xml syntax

csma: does the semantics need presentation syntax rather than abstract syntax?

Michael: order by akwardness - asn, abstract, presentation from hardest to easiest

csma: are we sure they are equivalent?

Sandro: no sure, believes so, nnott implemented converters for all cases

csma: don't need complete equivalence just that the specification of RIF is same in each case

Harold: As Axel pointed out, there were problems with asn07 for things like fixed cardinality for equals

Sandro: it is the mapping from presentation syntax to XML syntax is the core thing that has to be normative, all else is just editorial

csma: does semantics need to be explained only for the presentation syntax?

Jos: if have an abstract syntax would expect that to be normative, define syntax in terms of that, but can equiv specify semantics in PS and have formal xform from AS to PS

csma: if we need a normative AS do we have concensus on AEBNF?

<AxelPolleres> THe problem with devising an abstract syntax notation and its semantics is not really necessarily the scope of RIF, honestly. I think of what we want to do with asn, we could still do it with OWL, see:

<AxelPolleres> http://www.w3.org/mid/45DC13B1.4010404@urjc.es

Sandro: depends on its purpose

Michael: asn is more like a data model

Sandro: right!

<AxelPolleres> (my slides presented in a previous F2F)

Michael: don't need an AS just a syntax for defining the semantics, if also want a data model then do that separately

csma: what would be need a normative data model for?

Jos: isn't that for extensibility

Sandro: would accept asn not normative for now

csma: extensibility would be a argument in favour of having normative data model

Michael: thought is more like metaprogramming - manipulate rule syntax by rules, looks more like an API

Jos: in that case doesn't need to be normative

Axel: comes back to the ontologisation of RIF, does similar job to asn
... so do we fix problems in asn or fall back to OWL?

Sandro: asn just subset of OWL with simpler syntax

Axel: need more formal specification of that

Dave: PRR is specified in terms of data model, is the reason for keeping a data model rep of RIF

csma: XML syntax of RIF must be a concrete syntax of PRR metamodel, doesn't require RIF has it's own metamodel but do want RIF XML syntax to be compatible with the PRR metamodel

Axel: whenever we make changes at the moment have to change both asn and syntax, better to keep them apart

csma: maybe come back to PRR alignment when we talk about the rule syntax
... if motivation of asn is extensibility couldn't it be that in BLD xml is normative, then in arch document explain how to go back to AS extend then go forward again
... then would need to decide now if AS is normative or not

Sandro: fine with talking asn and UML out of next draft, or say informative

Hassan: any programming language design regards the abstract syntax is the normative one, it is the one for the semantics - any surface syntax will then be OK

csma: many implementers will only look at the XML schema and implement it, so it has to be normative

Hassan: the semantics is about the essential constructs which means the abstract syntax

csma: ANSI std for C etc don't they include the surface syntax in the standard?

Hassan: disagrees

csma: RIF is about interchange so the interchange syntax has to also be normative

Sandro: the abstract syntax doesn't have to be visible to the rest of the world, doesn't go over the network

Hassan: talking about any tree representation of AS - asn07, KM3, whatever - so long as it is 2D and directly corresponds to the tree

csma: concrete syntax used to explain the semantics, concrete syntax used for the interchange, abstract could be hidden as part of the arch document

Hassan: I as implementer would implement the abstract syntax

Harold: engine implementer is interested in the schema, but the users are interested in the instance documents which are in XML

Hassan: how are you going to guarantee the surface syntax is correct if you hide the abstract syntax

<AxelPolleres> As for "exhange is usually done in XML"... there are counterexamples... starting, but happening: People actually do start using things like Turtle to exchange RDF, look at pingthesemanticweb.com people *do* publish/exchange RDF in Turtle/N3 as well. (just a comment, I know we have XML in our charter ;-))

Axel: Hassan saying the exchange syntax must reflect the abstract model

Bob: are you saying we should use the abstract syntax as the mean of communication?
... as a programmer I have to work with the concrete syntax
... what do I translate my rules to an abstract or a concrete syntax?

[Clarification the Hassan is indeed talking about abstract syntax in the sense of tree structured reprsentation as in AHU et al, so XML schema is isomorphic to that]

<AxelPolleres> I would like propose some fixes in the abstract syntax/UML if we make it normative. E.g. the ordered/cardinality issue.

csma: raise an issue to capture this discussion on which is normative, need editor for the issue

Michael: you agree that giving semantics direct to XML syntax is painful, so need linear concrete syntax for writing down the semantics, but XML syntax has to be nomative so the mapping from the concrete syntax used in in spec to the XML needs to also be normative

<AxelPolleres> ...OWL seems to address cardinality. What about ordered attributes (like ordered paramterers in terms)? This could be, instead of an "ordered" flag, be tackled with a "position" property for paramerters. (getting already to technical detail here.)

Michael: for the mapping to be "correct" need semantics on both sides to verify the mapping is correct

<AxelPolleres> ... if we'd use that, I think I'd be fully happy with the abstract model.

Discussion on the AS/PS/XML triangle which mappings between them are needed

Michael: the PS is the one that has the semantics so that is the only one that has to be normative

Hassan: the semantics is on the AS, even if written down on PS, there is an arrow from PS to AS
... what is binding is how to treat the AS constructs

csma: Hassan is saying the XML schema is one representation for the AS

<AxelPolleres> Let me summarize my overall understanding of RIF rule interchange:

<AxelPolleres> 1) We have a *GENERIC* abstract model for conditions, rules, etc.

<AxelPolleres> 2) syntactically, the XML exchange syntax MUST reflect/express this abstract model

<AxelPolleres> 3) What is a dialect:

<AxelPolleres> a) it MUST restricts/define which parts of the abstract model you are allowed to use and how

<AxelPolleres> b) it MUST assign a semantics to this restricted part (model-theoretic, proof-theoretic, operational in that order of preference)

<AxelPolleres> c) it MAY assign "roundtrippable" own syntaxes (arbitrary many, if you want ;-) ) ... and even define the semantics in terms of one of those special syntaxes

<AxelPolleres> 4) BLD should define a minimal dialect and other dialects MUST agree withthe semantics of BLD *on the part of the abstract model they share with BLD

<AxelPolleres> Would I get a minute to present this on the projector? ;-)

<Hassan> I agree with Axel's approach!

Michael: what's wrong with the linear syntax? BNF specifies a tree right.

Hassan: the BNF specifies lots of irrelvant details that distract from the AS
... things like punctuation

Michael: so formally we'll have a tree but when we write it down we use this surface syntax, this is equiv to having a bidirectional mapping or at least map from PS to AS
... but the mapping has to be normative to carry the semantics

Hassan: the semantics is attached to the AS, the PS is just a way to write it down but the semantics is being given to the tree

csma: propose that we resolve that the XML schema will be normative

<AdrianPa> AST (abstract syntax tree) are two-dimensional trees they can encode the structure (as determined by a parser) of the input as well as the input symbols.

csma: propose that we raise an issue how to link the semantics to the XML schema

Michael: objects to how long are going keep the issue open, surely we need a draft in October?

Axel: does not matter which syntax we define the semantics in, so long as it is round trippable
... doesn't want to lock in the normative XML Schema for BLD if it locks the schema giving problems for other dialects

Sandro: the opposite would be to say that the mapping from PS to XML is normative

Jos: agrees
... XML schema is not a complete specification of the syntax of the language (scribe is confused)

Sandro: a long time ago we had a algorithm for mapping from PS (in BNF) to XML, perhaps we should just back to that

<Harold> Here is a simple example why we use the presentation syntax for the semantics: It's easier, in the semantics, to state, on the presentation syntax level, I |= head :- body than, on the abstract syntax level, I |= Implies(then->head, if->body). Even harder, in the semantics, to state this on the XML syntax level.

csma: then you don't have an XML Schema

Hassan: this the approach I'm taking

<AxelPolleres> The only misconception which we still have is how tightly coupled the abstract model is to the presentation syntax... that means that the "simple" mapping to the abstract model, ie. deriving the abstract model to possibly limiting assumptions in BLD seems to possibly create lock-in situations for later extensions. That's my whole point.

<AxelPolleres> +1 to Harold, that is in the spirit of 3)c) above.

Michael: any example of giving semantics to 2D language?

[not as scribe] -1 to Harold, saving a few characters is irrelevant

<josb> -1 to Harold; agree with Dave; a few characters more or less doesn't matter

Michael: both sides of the translation must be normative

csma: have to put this on paper

<scribe> ACTION: Hassan to clarify the relationship between AS, PS and semantics [recorded in http://www.w3.org/2007/09/27-rif-minutes.html#action01]

<rifbot> Created ACTION-346 - Clarify the relationship between AS, PS and semantics [on Hassan Ait-Kaci - due 2007-10-04].

<AxelPolleres> clarification: with my +1 I wanted to state that defining the semantics in whatever is most convenient is perfectly fine for me. Not whether the first or the latter of his was this most convenient one.

ScrribeNick: BobMoore

<scribe> Scribe: Bob Moore

<ChrisW> ScribeNick: BobMoore

Sandro - should we have a break

csma - only if you agree with me

Dave - does not think that having all 3 syntaxes without defining which is normative is a good idea

csma - need to have XML schema in next draft

<Harold> DaveR and Jos, as you know, the semantics is often given to pieces of text, inline. It would be much harder to use the abstract syntax, inline, in this way. However, the Abstract EBNF is at least textual and *could* be used for the semantics.

micheal - can't be all normative without proof of equivalence

Dave - could do

csma - thinks we can leave this open in the draft

Chris would like to figure out what the issue is as far as all are concerned and what people think the options are

Yes we'll let you know

<ChrisW> After the break, answer:

<ChrisW> What are we talking about?

<ChrisW> What are the choices?

<ChrisW> Which choices do you prefer?

<csma> Hassan, we are reconvening

Chris summary - Michael wants a contcrete syntax to define the formal semantics because he has issues about doing this within an abstract syntax

Michael comments specific example with regard to repeated argumetns only using DTD to work with

Chris has no particular view as to which is the best way of doing it

<sandro> csma: three roles: 1 xml syntax, 2 presentation syntax, 3 syntax for data model

<sandro> (my words, not his)

csma - three roles to be achieved - something to define XML, something to define semantics, somththing for data model

csma - could use XML to stand for both XML and semantics

csma - translation from rules to RIF should be a secure process - ie translation process should ensure that output XML is syntactically and sematically valid

<sandro> Sandro: We are talking about the PS-AS-XS triangle

<sandro> Sandro: The choices are whether to us an AS, and if so, what the AS is like

<sandro> Sandro: My preference if I were doing this alone would be to us asn07; but in the context of this WG let's just use the PS-XS line.

<csma> My preference would be to use the XML schema to specify the semantics as well, so that we would have only one norm (the XML schema); we may keep other (informative) representations for readibility

Dave - basically not sure that the abstract syntax is necessary, but it has some advantages and could be used to provide a single point of support

preference is to keep all three and keep the abstract syntax as the focal point

<csma> If specifying the semantics for the XML schema is impossible or too much of a burden, I would support having a concrete syntax (EBNF) to specify the semantics, and a mapping between AS and CS

<sandro> BobMoore: concrete syntax, with semantics attached, and a mechanism for moving from that to XML. The AS doesn't seem to play an enormous role. Whenever you're implementing, you'll use some sort of AS, but in fact you can use different AS's -- the AS doesn't have to be unique. If the semanics hang off the PS, then let's start there.

<sandro> BobMoore - so the PS has warts, but people can build up from it.

<sandro> BobMoore: so the PS has warts, but people can build up from it. we still need the XML Schema eventually. We're always going to be a position of generating things which are semantically meaningless but syntactically correct. At best we can avoid having things be syntactically problematic.

<sandro> BobMoore: If we work from the assumption that the rules are valid in the first place, then we don't need to worry too much about making the schema restrictive.

<sandro> BobMoore: there may be no semantics for some Syntactically Valid XML documents.

<sandro> Chris: Well -- there may be restriction you want to put on a DIALECT.

<sandro> csma: If you know the semantics of a dialect ..... garbage in garbage out.

<sandro> Chris: it's not about correctness, it's about the boundaries of a dialect which can or cannot be expressed.

<sandro> MichaelKifer: eg DTDs are CF, but FOL is not a CF language.

<sandro> DaveReynolds: things like declaration/use are part of syntax specification of a language, but not in the BNF

<sandro> (various): where is the syntax / semantic line here?

paula - need a presentation syntax, but also need an abstract syntax if we want to extend things, and the XML is also needed so she would like to keep all three syntaxes

Harold has some slides to show his ideas

Basically his view is that the instances are effectively isomorphic so the "correctness" of all the syntaxes/semantics is implicit

Is any presentation of an abstract syntax still abstract?

Are the examples of the use of the Abstract Syntax actually a concrete syntax?

Harold - we need the abstract syntax to keep in tune with the way other groups are going

<Hassan> Everybody agrees about the triangle and maintaining each three reps consistent with one another. The point is which is normative!

Harold - since he has demonstrated a translation process between abstract and concrete syntaxes they are essentially isomorphic

<DaveReynolds> Dave position summary:

<DaveReynolds> Issue: Need linear notation for writing down semantics (PS), XML syntax

<DaveReynolds> (XS) for interchange and link between the two.

Harold - could in theory "lift" the semantics from the concrete syntax to the abstract layer

<DaveReynolds> Desirable to have one point of maintenance (AS) to similify extensions,

<DaveReynolds> from which both PS and XS can be mechanically derived.

<DaveReynolds> Options:

<DaveReynolds> (1a) No AS, direct mapping for PS to XS.

<DaveReynolds> (1b) As (1a) but make PS as minimalist as possible, close to abstract

<DaveReynolds> syntax (i.e. in style of OWL) rather than half-way to syntax in which

<DaveReynolds> people would actually like to write down rules

<DaveReynolds> (2) Have a abstract (tree, 2D) model with a bidi map to PS, map to

<DaveReynolds> XS. Notation for directly writing down AS (KM3, asn) as a single point

<DaveReynolds> of maintenance.

<DaveReynolds> Preference: for (2) would accept (1b). Prefer 2 partly for maintenance

<DaveReynolds> argument. Concered that current spec has lots of things about escaping

<DaveReynolds> and mangling representations (e.g. handling of rif:text) which are

<DaveReynolds> only relevant to PS and not to XS or processing.

Michael - his thinking is to make the concrete syntax more abstract (to the point at which it becomes painful to use)

Michael - his thinking is to make the concrete syntax more abstract (to the point at which it becomes painful to use)

Effectively the idea seems to be to merge the concrete and abstract

Jos - thinks it might be an idea to raise the issue of linear vs non-linear syntaxes

Jos - XML schemas are not linear (?)

Axel - happy with EBNF presentation syntax for semantics, have an abstract model with several abstract syntaxes

Axel - he doesn't really see that there is a real difference between the EBNF, ans07 and XML schema syntaxes

Alex - some issues arise in the abstract model with regard to ordering and cardinality

Alex - these are possibly because we are trying to base the realisations of the abstract syntax too closely on the presentation syntaxes

Alex - only need to have a mapping from presentation syntax to XML

Axel - don't really need to make the presentation EBNF more abstract

Mike - thinks the XML must be "normative" as this is what people will actually use

<AxelPolleres> I paste my views in irc now... (sorry, this is a bit lengthy):

<AxelPolleres> I) EBNF (presentation) syntax and defining semantics of BLD

<AxelPolleres> in terms of it, is perfect for me. (maybe trying to minimize

<AxelPolleres> punctuation as far as possible, as proposed by Dave)

<AxelPolleres> This should be normative!

<AxelPolleres> II) Abstract model needs re-thinking at some points (order, cardinality), which

<AxelPolleres> I think are easy to fix... (I can try to work my concrete proposal out till tomorrow.)

<AxelPolleres> 3 concrete technical problem in the current abstract model:

<AxelPolleres> 1) order, cardinality

<AxelPolleres> 2) no distinction between

<AxelPolleres> c

Mike - he's not really sure what "normative" means

Mike - he's not really sure what "normative" means

<AxelPolleres> and

<AxelPolleres> c()

<AxelPolleres> ( not even in presentation EBNF, while we do have a distinction

<AxelPolleres> on the semantics level, easy to fix, allow

<AxelPolleres> Uniterm ::= Const

<AxelPolleres> )

<AxelPolleres> III) We can (and probably should!) fix these issue in the abstract model/syntax

<AxelPolleres> and proceed to an XML exchange syntax now for BLD from it along with back

<AxelPolleres> and forth mappings for representation EBNF. This exchange syntax

<AxelPolleres> could/should(?? to be discussed) leave out BLD specific restrictions.

<AxelPolleres> I would rather like to keep the abstract model presentation at UML diagrams

<AxelPolleres> at this point for the WD

<AxelPolleres> If we get it fixed, we should make the syntax and the EBNF/XML

<AxelPolleres> mappings normative as well (leaving open possible changes

Mike - He is happy with triangle approach for future things

<AxelPolleres> see next point).

<AxelPolleres> IV) The final (interdialect) exchange syntax should be based on the

<AxelPolleres> earlier mentioned mentioned points. particularly we should leave

<AxelPolleres> the door open to add such an interdialect exchange XML later on

<AxelPolleres> (we might still find more missing points when we focus on other dialects)

<AxelPolleres> V) BOTH XML and EBNF could IMO be allowed exchange syntaxes for BLD.

<AxelPolleres> XML will play a role mainly for interdialect stuff later on.

<AxelPolleres> VI) Triangle is rather two levels:

<AxelPolleres> PS: EBNF

<AxelPolleres> AS: asn, aEBNF, UML and derived XML

<AxelPolleres> P.S.: I personally think that the XML does not need to be convenient, but extensible in first place, see V) above.

Stella - XML is required, does not think that the abstract EBNF is very useful

csma - wants clarification on if we "need" a syntax - does it mean that the syntax is normative

general view is "need" means "normative"

Adrian - concern is that to build translation tools we need to have some keep some kind of normative syntaxes

Hassan - of view that the normative syntax should be the abstract one

Igor - would like to stick with the presentation syntax as the normative core syntax

<Hassan> Hassan: shares Dave Reynolds's point (summed up above on IRC) and Mike Dean's XML being normative. The triangle three reps are simple to keep consistent by operational means.

<sandro> Chris: everyone agreed we need a presentation syntax in the BLD document?

Chris - summarize so far - everybody thinks we "need" a presentation syntax in the document (need not be normative)

<sandro> Chris: We need an XML syntax for interchange

<sandro> Chris: We need an XML syntax for interchange (everyone seems to agree)

Chris - summarise so far - everybody thinks we need an XML schema (this will need to be "normative")

Chris - summarise so far - not everyone thinks we need an abstract syntax (though a lot do!)

Chris - summarize so far if we have two syntax there is (potentially) a consistency problem

<sandro> Harold: instead of "abstract syntax" we could call it "intermediate syntax" or "intermediate language", and such an intermediate language is very helpful to define semantics and translators.

<sandro> +1 Harold

<sandro> Example of mapping from PS to ....

Jos - we don't "need" semantics on the XML

Harold - yes we do

Sandro - looking at OWL have mapping table for mapping syntax (and hence semantics) between presentation and XML bypassing abstact syntax

<Harold> In order to show that the translator is semantics PRESERVING we need to define the semantics of the XML syntax, too, which is not so easy technically.

Sandro - this is not exactly elegant

Jos - can specify semantics without covering off all the tokenisation issues in the EBNF

Chris - celar we need two syntaxes - is there a translation process between the two?

Suggestion is that the process should be "not difficult" but not "trivial"

<Harold> Jos, about your 2nd point, the Concrete EBNF for the presentation syntax goes down until, but does not include, the 'leaves' of the presentation syntax trees: these can be easily added WITHOUT CHANGING ANYTHING ON THE HIGHER LEVELS.

How can we be sure that the translation is bidirectional

<AxelPolleres> Ojo! THe OWL<->RDF mapping is, btw, NOT injective!

Several XML documents may map to same presentation (ie semantics)

there ought to be a canonical XML document which is the output of a particular presention syntax

Harold - the abstract syntax can act as a bridge between these which makes proving the mapping is easier to do by breaking it down into two stages

Jos has some doubts on how "trivial" translation from PS to XML even if we modify the PS

<Harold> class2token('Equal','='), class2token('type','^^'), class2token('Var','?'), class2token('Implies',':-'), class2token('slot','->'), class2token('Instance','#'), class2token('Subclass','##').

<AxelPolleres> there is no "name" or value" token

<AxelPolleres> for consts... this contracidcts the full-striping in some extent, I think. (just a remark)

<sandro> OPTION 1: Change PS to have a simple mapping

<sandro> OPTION 2: Use AS (abstract model) as Interlingua XS <-> PS

<sandro> OPTION 3: Readable PS with complex XS mapping table

<sandro> (OPTIONS for mapping XS <-> PS)

<sandro> 1 -- gives a verbose PS

<sandro> 2 -- lets us have terse PS

<sandro> 3 -- lets us have a terse PS

<josb> I have doubts about the difference between 1 and 3, unless 3 means that the PS cares about encoding of symbols

<sandro> Option 1- 2 people

<sandro> Option 2- 6 people

<sandro> Option 3- Option 3- 3 people

<sandro> Option 3- 4 people

Votes 2 for number 1, Votes 7.5 for number 2, Votes 4 for number 3

Gary only gets half a vote

Break for lunch

<AxelPolleres> The question we are talking about seems to me:

<AxelPolleres> 2) PS <-> intermedaite abstract syntax <-> XML

<AxelPolleres> 3) PS <-> XML <-> abstract model (e.g. in UML)

<Harold> Yes, and you just said an intermediate abstract syntax, ie. 2), could be helpful?

<ChrisW> people are starting to trickle back into the room

<ChrisW> we'll start in a few mins

<ChrisW> restarting - anyone joining on the phone?

Data Models, Data Sets, Application Data, etc

<PaulaP> first subject: external data and RIF

<PaulaP> csma asks Dave whether or not he prepared some slides

<PaulaP> Dave: perhaps my slides are out of date

<ChrisW> Scribe: PaulaP

Dave: but, yes I have some slides

<ChrisW> Scribenick: PaulaP

Dave: data models, data sets, application data *
... I tried to determine the requirements regarding these issues and RIF

Dave explains his slides

Dave: important questions are:

how to identify a data set?

how to identify the data model?

how to access the data?

and...how to access the data model?

Dave: probably we do not need to answer all these questions
... most of our use case imply external data sets

MichaelK: except one or two use cases

Dave: Rif has to support access to data in non-Rif formats
... formats are XML, RDF, and an object data model
... probably many data models needed in a ruleset
... so, we have a couple of non-requirements
... exchanging rulesets working on different data models
... exchanging data models
... how many data models? what kind of object models?
... probably suffiecient to support XML for exchanging data and XML Schema for defining the data model
... then use an object model, which is to be accessed by the rules to be interchanged

csma: no need to interchange data if the object model is known
... most interesting case from the biz rules community
... other issues exist but are out of scope for Rif

Dave: for example MOF has been used in practice for applications
... RDF/OWL...Jos did some work here but there are still open issues
... combining the RDF semantics or just access RDF data?
... this issue is to be discussed later on
... let's look at the typical XML processing model
... people provide data, a consortium provides the schema
... usually a validation step
... then connect your data to a processor
... usually translate the XML data to an object model
... to be used for processing
... so, the four questions from the beginning are now a bit different

BobMoore: it should be irrelevant where the instance data comes from

Sandro: so the question is whether you can do that between different vendors

BobMoore: the problem regarding the source of instance data is completely outside the Rif mechanisms

csma: to write rules for an application you need a processor and an object model

BobMoore: but this should be outside Rif, so what is the scope of this proposal then?

csma gives an example to convince Bob

csma: of course it remains to be discussed if this is to be covered by Rif or not
... we need XML to object translator

Sandro: there are different ways to map XML to an object model

BobMoore: but what if I have different implementations of the translator?

csma: there is no problem in our setting

AdrianP: do we ask queries and answers?

csma: Rif is about interchanging queries and not evaluating them

Dave: going back to the original questions
... the questions are not different, we look at how to answer them
... metadata for identifying data set and data model
... acces the data schema is not an important req at moment
... we need to discuss how to specify this metadata for identification
... accessing the data - we need a way of doing the mapping
... map an external model to Rif
... is one of the alternatives
... instead of having many mappings, we could a generic mapping

between XML and Rif based on an existing XML to object map

MichaelK: you are talking about mapping data not schema

csma: it is a schema-aware mapping

Sandro: the mapping is different depending on the schema you use

Dave: in the Java world there is a way of mapping the XML data to the Java object model

MichaelK: but in this case you have schema on both sides

csma: you have rules about data not about data schema

<ChrisW> Gary, Igor, Hassan, MoZ if you want to join on the phone let me know. Right now the meeting room is not dialed in.

Dave: we need to know what is the identifier for an object

Jos: but it is not clear since not clear what these identifiers are

Dave: so you have three levels
... use sawsdl:modelReference if the schema element has one such annotation
... use existing algorithms for forming URIs
... giving an XML schema get a corresponding complex type
... the third question is 'do we always have to have a schema?'

use rif:local in this case

csma: I agree with everything you have presented
... but there are many DTDs around

Harold: one can use e.g. XMLSpy for translation

Dave: DTDs are not namespace-aware
... so you can invent a namespace for the DTD and then use the same method

csma: comments? discussion?

Jos: why do we need to take the XML schema into account?

Dave: I like to have URIs for the element names and objects
... so you can't get them from the XML document only

BobMoore: we should take a specific example

<GaryHallmark> can you dial in to Zakim

<Harold> Bob refers to this example from the eds' draft:

<Harold> Forall ?item ?deliverydate ?scheduledate ?diffdate

<Harold> (

<Harold> reject("http://example.com/people#John"^^rif:iri ?item) :-

<Harold> And ( perishable(?item)

<Harold> delivered(?item ?deliverydate "http://example.com/people#John"^^rif:iri)

<Harold> scheduled(?item ?scheduledate)

<Harold> timediff(?diffdate ?deliverydate ?scheduledate)

<Harold> greaterThan(?diffdate 10) )

<Harold> )

<Harold> ... saying that things like perishable could be defined in the XML Schema.

Dave: the primary mechanism for agreement in this world is the schema
... the schema tolds you also what the complex types are

ChrisW: in the translation you don't have the data

Jos: right, you have the variables in rules
... so you have additionally the type information
... but if you have an agreement on the schema, any XML data takes implicitly this schema into account
... in the case of XML data, not schema, you don't have the frame and object type

MichaelK: is this not a problem when exchanging between engines with different object models?

csma: the assumption here is that you have to know the schema, you have to know how to map them into your object model for using the rules

MIchaelK: but this is exactly the problem
... I don't wnat to have to know multiple mappings, I would like to have just one mapping - to Rif

ChrisW: you just need to have a mapping from XML; RDF, or Rif

MichaelK: but we do not have a schema in Rif

ChrisW: each ruleset is written based on an object model

Dave: I ignore the rules accessing the schema
... but there is a mapping from the instance data taking the schema into account
... to a Rif mechanism

csma: for future dialects we'll have extensions
... this proposal is for BLD

<Harold> Micheal, the example you gave -- If someone is a person then their spouse slot must be of type person -- is a integrity (constraint) rule testing a kind of schema compliance: one way to 'simulate' a schema language in RIF.

<AxelPolleres> Dave, can you send your slides to the list?

<ChrisW> Scribe: Harold Boley

<ChrisW> scribenick: Harold

Jos: Only parts of DaveR's slots are derived from XML Schema.

Sandro: You have to be fully striped -- most XML is not.

Jos: You only talk about class names or property names.

Sandro: You can't tell what is a class name and what is a property name.

Chris: Rules tell you what is what.

Christian: When you translate you dont have the data. Whats the use case?

Jos: Someone has no (XML) Schema.

Christian: Some other kind of agreement? Even better for us.

Michael: If you send out XML separately you dont need XML Schema.
... Schema only needed if you translate something to RIF.
... The 'other guy' may not have XML Schema (instead, say, DTD).

Chris (flip-chart): What use cases are emerging?

1) Rules + XMLS

2) Rules + XML data

Christian: Example, Blaze, Fair Isaac, and Ilog are Acord (or Mismo) compliant, so can interchange rules relative to this model.

Bob: Slightly different perspective, making things simpler (rather than more complicated).
... Slide: Abstract Rules (Object Model)------RIF------------>Concrete Rules (Object Model)

^ ^

XML Schema

<ChrisW> Clarifusion: The state of being confused by a clarification

<sandro> rofl

<sandro> But it's so simple, Chris!

Christian (discussing that slide): Lets table this until we have an example.

Michael: If you dont send a schema along with your rules the other guy may not be able to interpret those rules.
... I use database, u use Java, we need to agree on a common schema.

Christian: that could be an XML Schema.
... because many know how to translate to XML.

Sandro: We need to specify how to map from databases to Java (using RIF).

<sandro> uh, no. Sandro: We need to specify how to map from XML instances (which might represent java info or database info) into RIF ground terms. Whether that translation is really done is irrelevant.

DaveR: Learned that transmitting in XML is not always the case. XML Schema is wide-spread, but not necessarily the data.
... how to relate that agreements to the instance data (maybe with the help of RIF)?

Michael: Naive approach would be into and out of RIF, but not necessarily the final way.
... principled way in RIF, other ways could be derived from it.

Sandro: JAXB could be our starting point.

DaveR: Existence proofs and guidelines.
... for object models.

AdrianP: In the Web Service Community such translations are done.

Sandro: Does such an algorithm suffice in this industry?

DaveR: Object Model should cleanly align to the XML Schema.

Christian: A challenging example is how to count elements. E.g., first collect all elements, then count the cardinality of the resulting collection.

Related to earlier issue External Datamodels.

Jos: Not related to upcoming BLD WD release.
... separate issues are interoperation with RDF and XML.

<sandro> Issue: Interoperation with XML

<sandro> Issue: Interoperation with Object-Oriented XML

<sandro> Issue: Referencing Datasets

Jos/Sandro: General issue is External Datamodels.

<sandro> DataSETS noit DataMODELS

Sandro: Only Object-Oriented XML (use) is relevant here. E.g., not XHTML.

<sandro> Sandro: It's important to distinguish between MISMO-style (Object Oriented) XML, and general (DOM-style) XML.

<sandro> csma: addressing datasets

<sandro> csma: rdf compatibility

<sandro> csma: general (DOM) XML data interop

<sandro> csma: object-oriented XML data interop

<ChrisW> ACTION: dave reynolds to edit "addressing datasets" issue [recorded in http://www.w3.org/2007/09/27-rif-minutes.html#action02]

<rifbot> Created ACTION-347 - Reynolds to edit \"addressing datasets\" issue [on Dave Reynolds - due 2007-10-04].

<ChrisW> clarify dAVEr's action is to edit issue 32

Michael: Why are these separate issues: Referring to other ruleset is already an issue, data (facts) is just a special case.

AdrianP: Also includes question how to select (parts/segments of) external sources: XPointer etc.

We (Hassan, Michael and I) had an external Call primitive (which could also be used for fact sets) in collaboration with Gary, but it was taken out of the earlier Core document.

(This is related to a 2005 paper, with Jos, on a Realistic Architecture for the Semantic Web.)

<sandro> DR: new issue? Referring to external data sets

<sandro> DR: new issue? Importing rule sets (include rule modularity)

<sandro> DR: new issue? Interoperation with Object-Oriented XML, using XML Schema (like JAXB)new issue? Interoperation with Arbitrary XML (like SAX/DOM)

<sandro> DR: new issue? black boxes....?

<sandro> Chris: Referring to external data sets (new title for issue 32)

<sandro> Chris: new issue: Importing rule sets (include rule modularity)

<sandro> Chris: new issue: Interoperation with Object-Oriented XML, using XML Schema (like JAXB)

<sandro> Chris: new issue: Interoperation with Arbitrary XML (like SAX/DOM)

"black boxes" correspond to the "external Call" primitive.

<ChrisW> Scribe: Michael Kifer

<ChrisW> scribenick: MichaelKifer

Session on frames, classification, semantics, etc.

no issues with the frame syntax&semantics

issue whether class membership&subclassing is needed in rif

<sandro> Axel: two axioms -- transitivity of subclass, and membership commutes over subclass.

<AxelPolleres> rdf:type would/could be a "subproperty" of "#", yes?

<AxelPolleres> likewise rdf:subclass and ##, yes?

<sandro> DaveReynolds: I want to use XML data and RDF in the same module, but they have different ideas of rif:type, so the axioms I would add to match RDF-or-XML are different.

<sandro> DaveReynolds: (after long discussion) With a module system, my concern about overloading does go away.

<sandro> Chris: What is this module system?

<sandro> MichaelKifer: in different modules, you can have the same name meaning different things. so rif:subclass might have one meaning in one module and another meaning in another.

<sandro> MikeDean: I'm concerned about trying to map these different notions of type into one name.

<sandro> DaveReynolds: you can't axiomatize everyone's notions of subclass

<sandro> Jos: the two modules will touch, eventually, as you bring data from each of them together.

<sandro> Chris: It's not that they have different meanings, just .... [ something ]

<sandro> DaveReynolds: My preference is to translate rdf:type to rdf:type (not rif:type). Keep them separate.

<sandro> Harold: For interchange, we might need this.

<sandro> MichaelKifer: LP languages use this all the time. I might define a subclass of RedCars... the class hierarchy.

<sandro> Chris: you use the class hierarchy in reasoning a lot. so that's a reason to have this in rules.

<sandro> Chris: Professor subclassOf Person, rule about Person, data about Professor -- the rule system needs it all to fire on the data.

<sandro> csma: (disagreement)

<sandro> jos: It seems to me that # and ## are a way to access the data model.

<sandro> Sandro: how about making this At Risk for a while and see how it goes?

<sandro> DaveReynolds: (strong disagreement) It's one more way to do what we already have a way to do!

<sandro> Chris: This saves people two axioms!

<sandro> Axel: Do we relate this to RDFS:subClassOf ...?

<sandro> Jos: Chris, you say there are lots of systems that use this kind of type system, but where are they...?

<sandro> Chris: Jos, are you going to say that subclass is not the most common relation in logic-based languages?

<sandro> Jos: *shrug* okay, okay

<sandro> csma: The question is not WHETHER they have a subclass relation, but whether they express it in rules.

<sandro> MichaelKifer: You're thinking PRD, this is BLD.

<sandro> Chris: In the rule languages on our wiki page, most of them support a subclass relation as part of the syntax.

<sandro> csma: Is this really a commonly-used feature?

<sandro> Chris: Does anyone dispute that subclass is extensively used in actual rules?

<sandro> BobMoore: Almost all systems that I've been involved with make use of classes and subclasses.

<sandro> ... All things that belong to some category, .... this rules applies to entities belonging to this class.

<sandro> ... I don't see a lot of subclass, though, since most business rules object models don't use inheritance.

<sandro> csma: This is not about whether the engine does subclass relation processing, it's about whether people write rules asserting or checking subclass conditions directly.

<AxelPolleres> Proposed:

<AxelPolleres> 1) Add to RDF embedding:

<AxelPolleres> ?o#?c :- ?o[rdf:type -> ?c]

<AxelPolleres> 2) Add to RDFs embedding:

<AxelPolleres> Forall ?c1,?c2 ?c1##?c2 :- ?c1[rdfs:subclassOf-> ?c2]

<AxelPolleres> and remove:

<AxelPolleres> Forall ?x,?y,?z ?z[rdf:type -> ?y] :- And (?x[rdfs:subClassOf -> ?y] ?z[rdf:type -> ?x]),

<AxelPolleres> Forall ?x,?y,?z ?x[rdfs:subClassOf -> ?z] :- And (?x[rdfs:subClassOf -> ?y] ?y[rdfs:subClassOf -> ?z]),

<AxelPolleres> I would like to know concrete objections against this, if possible :-)

<sandro> Sandro: What about just having systems put in the axioms and recognize it if they want?

<sandro> MichaelKifer: i don't think you could recognize them -- that structure occurs elsewhere.

<Harold> Besides, or on top of, RIF's own 'built-in' subclass relation, "##", RIF will need to permit to write rules about (and with) other subclass relations, e.g. rdfs:subClassOf, my:subClassOf and your:subClassOf, and allow to axiomatize (and reason with) them with RIF rules. From F-logic -- http://flora.sourceforge.net/aboutFlogic.php -- and Wilbur -- http://wilbur-rdf.sourceforge.net -- to KAON2 -- http://kaon2.semanticweb.org -- rules have been used in such ways.

<sandro> Axel: I have a problem with rif:subclass not being related to rdfs:subclass in the relation.

<sandro> Chris: Okay -- enough about subclass. What about rif:member (#)? ANyone have a problem with that?

<sandro> Jos: I have a problem with it. It's not clear if we can have a standard way to do this.

<sandro> MichaelKifer: I think it's clear.

<sandro> Jos: It's not clear whether it can really be used.

<sandro> Axel: ... especially when we can't (don't) even use it for RDFS.

<sandro> ChrisW: DaveR's proposal for XML used this.

<sandro> Jos: it's doubtful whether XML's typing relation is the same as rif:member...

<sandro> Sandro: in general that's true, but in the object oriented XML community we're talking about, it basically is.

<sandro> MichaelKifer: You're forcing me to tack on RDFS....

<sandro> Jos: No, you can define your own data model.

<sandro> MichaelKifer: But this is standard.....

<Harold> Is ?x#c a type 'declaration' in the sense that all other occurrences of ?x (also without the "#c" part) must comply to that type restriction "#c"?

<sandro> Jos: I could be convinced if it matches enough data models.

<AxelPolleres> Would it make sense to limit discussion for another 5-10min and then just do a vote?

<sandro> Chris: 10 people think we need rif:member, 1 against.

<sandro> DaveReynolds: we might need it without a special syntax.

<sandro> Jos: Basically, I'm skeptical that we can link various data models. What instantiation means varies language-to-language.

<sandro> AdrianPa: for instance phone number vs number.

<sandro> Axel: We *can* reuse this, but we have to deviate from the obvious way to encode RDFS in rules.

<sandro> Chris: is this valid syntax: P(x) /\ x[q->y]

<sandro> MichaelKifer: yes.

<sandro> Chris: and it just means x's type is "P" ?

<sandro> MichaelKifer: sort of. except in terms of round-tripping.

<sandro> MichaelKifer: a frame is just a bunch of ternary predicate atoms, but we have them.

<sandro> Jos: Is P a predicate or a term?

<sandro> Jos: concete difference.

<sandro> BobMoore: This kind of thing makes the rules much readable. See if we use it in examples. (Sandro's proposal)

<sandro> ... If it comes up time and time again, it's worth having a special syntax.

<sandro> ... And it's nice as a hint.

<sandro> csma: Beware that "c" in the spec is a TERM, not just a constant.

<sandro> Jos: I'm okay with keeping it in this draft, but not with keeping it past Last Call.

<Harold> How can we keep straight the difference between '^^' and '#' in examples such as "101"^^xsd:long and 101#LongIntegers, where LongIntegers is used as the class of long integers?

<sandro> MichaelKifer: in the current BLD, there's not way to ask if a type applies to a variable

<sandro> DaveReynolds: I proposed it as a built-in.

<sandro> csma: the difference between ^^ and # is ....?

<sandro> csma: maybe make classes just be constants.

<sandro> MichaelKifer: "..."^^xsd:int should be defined to be in class int

<sandro> Chris: Propose we leave # in the document, resolve we accept it for now, but we need to get use cases, etc.

<sandro> ACTION: Jos open membership-formula issue [recorded in http://www.w3.org/2007/09/27-rif-minutes.html#action03]

<rifbot> Sorry, amibiguous username (more than one match) - Jos

<rifbot> Try using a different identifier, such as family name or username (eg. jderoo, jdebruij)

<sandro> ACTION: Jdebruiij open membership-formula issue [recorded in http://www.w3.org/2007/09/27-rif-minutes.html#action04]

<rifbot> Sorry, couldn't find user - Jdebruiij

<sandro> ACTION: jdebruij to open membership-formula issue [recorded in http://www.w3.org/2007/09/27-rif-minutes.html#action05]

<rifbot> Created ACTION-348 - Open membership-formula issue [on Jos de Bruijn - due 2007-10-04].

<sandro> rifbot?

<sandro> ACTION: DaveReynolds to write up use case on membership-formula [recorded in http://www.w3.org/2007/09/27-rif-minutes.html#action06]

<rifbot> Sorry, couldn't find user - DaveReynolds

<sandro> ACTION: David to write up use case on membership-formula [recorded in http://www.w3.org/2007/09/27-rif-minutes.html#action07]

<rifbot> Sorry, amibiguous username (more than one match) - David

<rifbot> Try using a different identifier, such as family name or username (eg. dmartin5, dhirtle, djones3)

<sandro> ACTION: DavidReynolds to write up use case on membership-formula [recorded in http://www.w3.org/2007/09/27-rif-minutes.html#action08]

<rifbot> Sorry, couldn't find user - DavidReynolds

<sandro> ACTION: Dave to write up use case on membership-formula [recorded in http://www.w3.org/2007/09/27-rif-minutes.html#action09]

<rifbot> Created ACTION-349 - Write up use case on membership-formula [on Dave Reynolds - due 2007-10-04].

<sandro> ACTION: Axel to write up use case on membership-formula [recorded in http://www.w3.org/2007/09/27-rif-minutes.html#action10]

<rifbot> Created ACTION-350 - Write up use case on membership-formula [on Axel Polleres - due 2007-10-04].

<sandro> (an example that shows how it can be used for RDF.)

<sandro> Keep subclass: 5, Not keep: 4.

<sandro> Really object to staying in DR, and J; really object to keeping it in: MK.

<sandro> ACTION: Michael to raise issue about subclass formula [recorded in http://www.w3.org/2007/09/27-rif-minutes.html#action11]

<rifbot> Sorry, amibiguous username (more than one match) - Michael

<rifbot> Try using a different identifier, such as family name or username (eg. uscholdm, merdmann, mkifer, msintek)

<sandro> ACTION: Mkifer to raise issue about subclass formula [recorded in http://www.w3.org/2007/09/27-rif-minutes.html#action12]

<rifbot> Created ACTION-351 - Raise issue about subclass formula [on Michael Kifer - due 2007-10-04].