RIF F2F8 - 28 Sept 2007 -- 28 Sep 2007

Change Abstract Syntax near "RULE"

<StellaMitchell> ScribeNick: StellaMitchell

<ChrisW> Scribe: Stella Mitchell

csma: showing current abstract syntax for rules

<ChrisW> who is CGI396

csma: problem with extensibility (for example for existential quantification), with the current scheme
... another issue: a ground class it still enclosed in a forall

harold: we resolved to enclose every clause in forall

csma: no, not every clause, every variable
... and, it we did resolve it, it was a bad decision

sandro: we can change our minds only if we get new information

csma: in summary, it is not extensible, ground clauses are enclosed in forall, and a minor issue that metadata is attached to a forall

<sandro> We're calling now IgorMozetic

csma: in June, I proposed an alternative, that doesn't change the semantics and only changes syntax a little

http://www.w3.org/2005/rules/wg/wiki/Core/Horn_Rules_Alternative

harold: we cannot syntactically enforce that the forall contains the approproate varialbes, because the syntax is context free

csma: that problem exists in both designs
... GaryH agreed that my proposal is acceptable

<ChrisW> CGI396 who are you?

<ChrisW> IgorMozetic, can you hear OK?

BobM: asking about cardinality constaint on clauses

<IgorMozetic> yes, I hear fine

csma: because of the design, if you have a rule, you must have a clause

<sandro> CGI396? Hello?

csma: (presents a minor change to his original proposal)
... clause was renamed to conditionalWithQuantifiedVariables and it moves above the forall
... I propose we adopt this symtax in place of the current one

jos: question - if there is implies without forall, do all vars still have to be quantified
... i.e. will free variables be allowed?

csma: the situation with free variables is the same in current syntax and this one

jos: I don't agree with the text of the proposed resolution - because of the particular wording
... but I have no objection to the design

harold: rule is a word that is too specific to FOL

csma: 1. we have to have that stretch anyway 2. this proposal only means the structural model, not the exact wording

daver: there is a use case for having metadata at the top level, and it doesn't hurt anything

harold: it violates a minimalist design

csma: our discussion time for this item is over, and we weren't able to resolve, so we will raise an issue

<ChrisW> ACTION: harold to raise issue about new structural model for syntax of BLD rules [recorded in http://www.w3.org/2007/09/28-rif-minutes.html#action01]

<rifbot> Created ACTION-353 - Raise issue about new structural model for syntax of BLD rules [on Harold Boley - due 2007-10-05].

(csma will send slides to the group)

XML Syntax - Root Element (rif:Document)

<ChrisW> sandro is on Arch/XML_Syntax on the wiki

sandro: (presenting slides)

http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax_Issues_2

<ChrisW> http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax_Issues/Root_Element

sandro: issue: what should root of BLD look like?

<ChrisW> harold suggested rif:RIF for the root element name

<ChrisW> http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax_Issues/Root_Element

jos: why did you use curie and not uri?

michaelK: and you didn't define "rif:" but you don't need it anyway

sandro: curie: I made it optional

jos: xml tools will not know about curies

sandro: but they will not know about dialects either

michaelk: it's ambiguous, because xml will think it's a namespace

daver, jos: no, that isn't right

harold: suggestion:
... about identifying dialet

axel: awkward for inter-dialect interchange

(writing overview of issues on the board);

1. use of curies

2. structure of uri's for dialect identification

3. how to identify dialect

sandro: my assumption was that I should use curies wherever possible

options for 3:

a: dialect attribute

b: rif: dialect document

MikeDean: why datatype attribute instead of object property for dialect?

<AxelPolleres> Side remark: CURI -> CIRI ?

<Harold> Option F: <rif:RIF xmlns="http://www.w3.org/2007/rif/BLD" xmlns:xs="http://www.w3.org/2001/XMLSchema#"> . . . </RIF>

sandro: rif:Document vs. rif:BLDDocument

harold: and I proposed another option above in irc

<ChrisW> Chair: Christian de Sainte-Marie

<AxelPolleres> I think we should not use different namespaces per dialect, that seems to lock out reuse of common elements between dialects.

sandro: what would use the default namespace?

harold: the second namespace is for extensions

michaelK: but it would be difficult to identify the dialect

harold: we need a modular approach

axel: concern (?)

(back to issues lists)

4. namepsaces

harold: do we want a tree of dialects or a deck (lattice) of them?

sandro: the issues we need to solve today are:

A. RDF?

B. Root = Dialect Specific

C. Root is "Document or RIF"

<AxelPolleres> Harold: Exactly what you say is why I want the core components to be labeled rif and not rifBLD... BLD already makes some restictions on the use of the core components (e.g. no forall in bodies, etc. which other languages would maybe want to allow)

sandro: any objections to making it not dialect specific?

harold: wants it be dialect specific

straw poll: should the root element be dialect specific?

any strong opinions on this?

show of hands

proposed: for WD2, the root element will not be dialect specific

<sandro> resolved: for WD2, the root element will not be dialect specific

<ChrisW> RESOLUTION: for BLD WD2, the root element will not be dialect specific

sandro: discussing name of root element

harold: "document" is too general

sandro: no, it would be rif:Document or rif:RIFDocument
... because I want to know what it is from an object perspective

MichaelK: let's be compatible with the other standards

<IgorMozetic> I vote for rif:RIF (for consistency with others)

proposed: root element will be rif:Document

<sandro> RESOLVED: root element is rif:Document

<ChrisW> RESOLUTION: root element is rif:Document

vote outcome:

rif: Document - 4 for, 0 against
... RIFDocument 2 for, 4 against
... RIF 5 for, 1 against

XML Syntax - Identifying Rulesets, etc (rif:identifier)

sandro: issue about identifying rulesets

csma: suggests "name" instead of "id"

<Harold> ID/IDREF in XML: http://www.w3.org/TR/xmlschema-2/#ID

<Harold> <length

<Harold> fixed = boolean : false

<Harold> id = ID

<Harold> value = nonNegativeInteger

<Harold> {any attributes with non-schema namespace . . .}>

<mdean> http://www.w3.org/TR/xml-id/

<Harold> Content: (annotation?)

sandro: we decided at f2f4 to use IRI

daver: re: options b, typcially they can still be relative uri's

http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax_Issues/Identifying_Rulesets

sandro: and I want to add another option to this list, for xml:id

daver: use relative uri's not ids
... will make rule merging easier

harold: it's legal to attach an id to any element
... mikedean pointed us to a 2005 draft about ids, above in irc

daver: suggested using rdf:about or something similar, instead of xml:id
... (and would not use curies, because they are more controversial)
... rdf:about is an attribute
... but I was not suggesting rdf:about exactly - just a relative uri in general

sandro: the basic choice is between ids (incl xml machinery) and uris

csma: ids restricting to one per document

daver: ids are a problem for merging

mikedean: rules should be uniquely named only within a ruleset?

csma, sandro; no

daver: with rdf syntax, we would get some processing for free - but that is a different issue

csma: poll between relative uris, and ids

vote outcome:

relative uris: 8

ids: 0

s/8/8 for/0 against/

s/ids: 0/for 0/against 1/

<mdean> scribenick: mdean

continue ArchXML Syntax Issues

http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax_Issues/Identifying_Rulesets

discussion of attribute names rdf:about or rif:<something>

rif: options: about, id, ident, uri, iri, oid
... iri is used elsewhere, which could cause confusion

globalID, globalName

Harold: also need attribute to refer to ruleset or rule?
... or is this only a handle for metadata?

name

Harold: oid is for frames only

take out uri and iri

Jos: identifier or id, not ident

Harold: possible confusion between id and xml:id

MichaelKifer: uniqueness requirements?

Chris: architecture of Semantic Web assumes URI are unique - not our problem that we can't enforce it

csma: could we use rif:about and express equivalence to rdf:about?

Sandro: mapping required, but not automatic

name: 6 prefer, 0 object

globalId: 1 prefer, 1 object

about: 1 prefer, 0 object

identifier: 3 prefer, 0 object

Chris: nobody expects names to be unique, but do expect identifiers to be unique

reconsider id?

Sandro: hasIRI?

Harold: metadataAttachmentPoint

<AxelPolleres> i like rif:tafkab

straw poll #2

name: 1 prefer, csma objects

id: 2 prefer, jos and chris object

identifier: 8 prefer, 0 object

hasIRI: 1 prefer, Adrian and Axel object

metadataAttachmentPoint: 1 prefer, various object

<sandro> PROPOSED: To identify rules and rulesets (and other syntactic objects needing identifiers) we'll use rdf:about or rif:identifier in the next draft.

<sandro> PROPOSED: To identify rules and rulesets (and other syntactic objects not otherwise having identifiers) we'll use rdf:about or rif:identifier in the next draft.

<sandro> PROPOSED: To identify rules and rulesets (and other syntactic objects not otherwise having identifiers) we'll use rdf:about or rif:identifier in the next draft. This is envisioned for metadata and should not affect the semantics.

<sandro> RESOLVED:: To identify rules and rulesets (and other syntactic objects not otherwise having identifiers) we'll use rdf:about or rif:identifier in the next draft. This is envisioned for metadata and should not affect the semantics.

<Harold> Comment: So, as we discussed, the identifier attribute is not meant for names within the language.

XML Syntax -- Should RIF XML Docs signal when position matters?

http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax_Issues/Positional_Arguments

<AxelPolleres> I propose: To identify order/position of arguments in uniterms (and other syntactic objects needing order) we'll use an rdf:position attribute in the next draft.

<AxelPolleres> ... seems to be option E.

Sandro: doesn't fit normal striping

Chris: perhaps fold position into parameter names

<Harold> Axel, Yes, we have in the draft that Opt. A is interpreted as

Axel: using the same attribute for name and position precludes named positional arguments

Michael: order is determined by semantics, can be done in XML Schema, why do we need it in instances?

csma: can imagine cases in other dialects where order of rules matters, e.g. production rules

<Harold> In http://www.w3.org/2005/rules/wg/wiki/Core/Positive_Conditions, section "XML serialization" we have

<Harold> - arg (argument role, positional/non-positional without/with optional 'index' attribute)

<DaveReynolds> Possibly helpful discussion of issues of ordering in XML: http://www-128.ibm.com/developerworks/xml/library/x-eleord.html

<AxelPolleres> another argument against using the same attribute for position and name nedds care excpluding position names as slot names.

csma: production rules typically distinguish sequential or not - necessary for round-tripping

Chris: issue: does order need to be indicated in RIF document?

<Harold> So like OPTION C2 and HTML reads <li><...></li> in sequence, so does the current draft reads <arg><...></arg> as <arg index="i"><...></arg>.

http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax_Issues/Positional_Arguments

Dave: XML parser can reorder arguments, though most don't

<csma> Gary, the discussion is whether (and how) to indicate order in documents, when the schema contains that information and the semantics as well

Dave: InfoSet is ordered

Bob: XML Schema can specify order

<csma> Chris: we are dealing with the case where the schema specify order

<GaryHallmark> +1 for option A.

Bob: implicit ordering of arguments

Sandro: consider rule set where rules are not ordered

csma: support schemaless parsing into unordered structures

Harold: preserve editing order
... e.g. as in Protege

<GaryHallmark> +1 for Harold's point. XML *is* ordered, and that's often a good thing

csma: assume ordered until semantic level

Axel: ruleset implies unordered
... should we use ruleprogram instead :-)

Dave: may impact ruleset merging - motivates unordering of RDF

<GaryHallmark> I want my rules in an XML document that I can edit, store, transmit, etc. Not in some unordered pile of triples...

csma: ordered for parser not semantics

<Harold> As I said, the Protege group at SMI, had the same discussion about whether to preserve class-definition order: although the semantic will *interpret* the definitions in an unordered manner (the order does not matter semantically), the Protege group decided to preserve the editing order so people can roundtrip through the tool without losing their editing order information (very helpful for documentary purposes).

Gary: XML is ordered

Dave: concerned about assuming everything is ordered

Michael: just make sure you preserve the semantics

csma: want some rules to be processed as ordered, property of ruleset not schema

<Harold> For multiple 'includes' the inclusion order could also be preserved for inspection and editing purposes, again without affecting the unordered semantic *interpretation* of the merged ruleset.

csma: what if new parser lost order?

<Harold> Bob, right, the repeated arg elements in

<Harold> are read as

Sandro: doesn't make sense to order properties

Axel: assuming XML syntax close to abstract model
... UML doesn't provide good way to indicate order

Chris: is redundancy needed in document so it can be processed without syntax specification

Sandro: ASN specifies ordered in some cases where it's not necessary

Dave: RDF is such an unordered representation

Sandro: output of RDF mapping is horrendous with lots of lists

straw poll: indicate order or not

Gary: how to tell from schema?

Bob: sequence vs. all

Gary: some restrictions on all

Michael: repeating elements OK

<Harold> "The all group (which provides a simplified version of the SGML &-Connector) is limited to the top-level of any content model. Moreover, the group's children must all be individual elements (no groups), and no element in the content model may appear more than once, i.e. the permissible values of minOccurs and maxOccurs are 0 and 1. "

<Harold> http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/

<Harold> (more precisely: http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/#groups)

Gary: editor could provide presentation order e.g. by label

<AxelPolleres> scribe: Axel Polleres

<AxelPolleres> scribenick: AxelPolleres

michael: restriction on order in XML not "severe" (michael: pls post a link?)
... discussing XML schema ALL directive.

Bob: ALL doesn't indicate that the elements should be *treated* unordered

Chris: Do we want to preserve order where not necessary by semantics, e.g. slotted terms?

Axel: I am worried about extensibility if we now go for the order to be always reflected.

<Harold> Axel, like in HTML you are allowed to say

Chris: this is not the question here.

<Harold> we can say

<Harold> and parse it as

Sandro (whiteboard): Is the semantics that it's not ordered to be reflected in every instance document?

scribe-hat off: Harold, I like that option, it caters for both sides in some sense.

Michael and Sanrdo: further arguing whether this plays a role for parsers, e.g. reading into a database.

michael: sql databases are ordered (rela alg. is not)

Bob: if we stick the information in the xml, what benefit do we get?

Christian: Sandro, if you want to put it in a triple store, it is not a question of the parser.

Sandro: unordered saves trouble in storing in triplestores, whereas order needs to be encoded in lists or by assitional sequence attributes.

<Harold> Axel, Yes, this is part of OPTION A.

scribe-hat off: Harold, but one is on pro and the second is on con side.

chris: who prefer to have order indicated?

4 pro / 8 against

chris: who would object order being indicated?

1 (bob)

chris: who would object to not indicate order?

2 (sandro, axel)

<Harold> Axel, as you said "it caters for both sides in some sense".

sandro: i can't do the implementation I want, then.

harold: It is not so tragic, in reality.

christian: bob's objection is different from sandro's objection, since bob said it doesn't make sense, whereas sandro says he cannot use his tools anymore.

chris (chairhat off): the fact that you can indicate oreder in XML (schema) seems a stronger argument for me.

sandro: but you don't know when order doesn't meatter then.

<Harold> Sandro's tool, which disregards the order of rules in a Ruleset etc, can still be used, but people will often also keep the original input Ruleset document because they cannot roundtrip through that tool.

<Harold> (So, the problem is a kind of duplication of the Ruleset, not that the tool is unusable.)

<ChrisW> gary - if you want to get on the queue, do it on IRC and the scribe will tell me

michael: ordered case is the more common one.

axel: would you then indicate unordered explicitly?

gary: order for AND is important, if we allow built-ins!

<Harold> Reading/Parsing <arg><...></arg> as <arg index="i"><...></arg> for the ith element is like HTML's use of <li><...></li>: a position-dependent default value for the index attribute.

bob: you may want to preserve the order for some cases

sandro: then don't use BLD

christian: OMG PRR has ben voted an alpha specification

chris: lunchbreak!

<sandro> PROPOSED: In WD2 there will be no indication of whether order has semantics in XML instance documents. The issue remains open for future drafts.

sandro/axel: we resolved a workaround for the implementation issue which sandro mentioned before the break during lunch, which we can live with for the moment.

<GaryHallmark> call Zakim when you start...

sandro: we still need a strawpoll: how many people prefer an XML/RDF syntax?

2 pro hands up

s/votes/hands up/

<sandro> we're dialing you in Gary

<sandro> PROPOSED: In WD2 there will be no indication of whether order has semantics in XML instance documents. The issue remains open for future drafts.

<sandro> Note that this implies WD2 will not have an RDF/XML syntax.

christian: (explaining to gary what we did before he dialed in)

<sandro> RESOLVED: In WD2 there will be no indication of whether order has semantics in XML instance documents. The issue remains open for future drafts.

no objections against proposed resolution.

<ChrisW> ACTION: Sandro to open an issue on where order has semantics in XML instance docs [recorded in http://www.w3.org/2007/09/28-rif-minutes.html#action02]

<rifbot> Created ACTION-354 - Open an issue on where order has semantics in XML instance docs [on Sandro Hawke - due 2007-10-05].

XML Syntax -- Serialization of Constants

sandro: 4th and last issue
... How do we serialize constants?

http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax_Issues/Constants

<Harold> Currently, we have "abc"^^xsd:string

<Harold> http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax_Issues/Constants

sandro: explaining the options outlined on that page.
... Opt A vs. Opt B: type as attribute vs. type as element, (Options to be read with respect to previous resolution )
... Opt C: special distinction for Literals

michael: tag names matter, because schema definition becomes complicated.

sandro: may hamper extensibility.

michael: what about unknown types?

(meta remark: discussing option B)

jos: technically any allowed tag can be done in XML schema.

michael: in Option A type could be anything

dave: ANY doesn't seem to be a solution

jos: in Opt you can say that type is a URI and a STRING inside ...
... ... but in Option B, using ANY you cannot restrict the content to be a STRING

chris: how do you indicate in Option B a variable?

<Harold> From Michael's email, in response to Jos, "Re: comments on BLD draft part I":

<scribe> scribe: Adrian Paschke

<Harold> > 17- section 2.1.2: it is unclear to me why the list of datatypes is

<Harold> > fixed. By fixing this list, every implementation needs to support all

<Harold> > mentioned data types, and no other data types can be used in

<Harold> > meaning-preserving fashion. I propose to make a list of datatypes which

<Harold> > need to be supported by every RIF implementation (e.g. xsd:string,

<Harold> > xsd:integer), and a list of additional data types which are recommended

<Harold> > for use with RIF (e.g. xsd:gYearMonth)

<Harold> The list of data types is not fixed. It is in flux.

<Harold> It is a minor issue, but I am not against recommended data types.

<Harold> Or, maybe, we could use a more general mechanism.

<Harold> We need to think what does it mean for an exchange language to "support" a

<scribe> scribenick: AdrianPa

<Harold> data type. Is it a matter of issuing an error when the lexical space is

<Harold> violated? To support certain inferences? If the latter, then I fail to see

<Harold> what does it mean to be a type "recommended" for use with RIF.

Christian: Opt C seperates seperates lterals from global and local

Michael: They are already seperated

Jos: Opt C makes a distinction between Local, Global and typed literals

Sandro: Does the XML Schema for BLD hard code and check the datatypes?

Jos: needs to fixed in the language and changes to the language are needed

Sandro: Define BLD for unknown datatypes

Chris: Decide if we need other datatypes?

Christian: Are datatypes extensible in BLD?

everyone but Sandro; no objection

<ChrisW> PROPOSED: Datatypes are extensible in BLD

Sandro: Two parties want to interchange some datatype not defined in BLD
... we could make a new dialect
... the parties should make a new dialect

Christian: BLD can be used easily if datatype are extensible
... your rule system will tell you if it can not understand the datatype

Sandro: BLD should not have a custom extension mechanism

Christian: Without a extension mechansimn you always needs to deploy a new dialect

Michael: Deployment of new dialects will be hard

Dave: OWL and RDF already adopted this approach and it was successful

Sandro: Which built-ins

Christian: Update issue about datatype exentsibility
... Reject option B, we are left with C and option A

Jos: We need to be consistent in presentation syntax, abstract syntax

<Harold> We adopted a uniform element name <Const> and don't even have element names <Rel>, <Fun>, and <Ind> distinguishing, respectively, the top-level entities of relations, functions, and individuals. OPTION C seems to introduce redundant distinctions Global, Local, Literal that are already in the rif:type attribute.

Sandro: Global, local, literal are only syntactic sugar for <const type="iri">

Michael: People will look at the presentation syntax

<Harold> While <Global>http://example.com/#r</Global> is indeed global, <Global>#r</Global> is not.

Prefer Opt A: 7; Prefer Opt C: 1.5;

<DaveReynolds> Harold: not true, a relative URI will be resolved relative to the xml:base

Sandro: Resolve RDF issue implicitly

Christian: What needs to be resolved for XML syntax?

XML Syntax - CURIEs?

Sandro: Const types are Curies, QNames, IRI?

Dave: Curies are not official

<Harold> http://www.w3.org/TR/curie/

Dave: types are all curies

Christian: but curries are not official

Michael: full URI

Mike: What about local?

Dave: it is rif:local

Christian: We have to specify meaning of curies

Dave: if we pick IRIs we are done

Curies prefer:0; full IRI prefer:9; curie+iri prefer:0; special syntax prefer:0/object: Jos

<sandro> PROPOSED: In the XML syntax, we'll use full IRIs (not qnames or curies) for Const types, etc. Of course, XML entities can be used.

Michael: QNames and IRIs are syntactically incompatible

<Harold> DaveR, but #r refers to the current document, say http://current.org, so is local to http://current.org: http://current.org#r.

<sandro> RESOLVED: In the XML syntax, we'll use full IRIs (not qnames or curies) for Const types, etc. Of course, XML entities can be used.

XML Syntax -- Identifying Dialects

Christian: Issue on "Identify Dialects in the XML document"

<sandro> PROPOSED: dialect is identified by an IRI, in the document as an attribute rif:dialect on the root element

objection: Bob

Bob: Several different dialects for rule sets

Christian: Keep this question in draft 2

<sandro> PROPOSED: dialect is identified by an IRI, which appear in the document as an attribute rif:dialect on the root element (for WD2, until we figure out extensibility)

<sandro> PROPOSED: dialect-of-author is identified by an IRI, which appear in the document as an attribute rif:dialect on the root element (for WD2, until we figure out extensibility)

<sandro> PROPOSED: dialect-of-authoring is identified by an IRI, which appear in the document as an attribute rif:dialect on the root element (for WD2, until we figure out extensibility)

<sandro> RESOLVED: dialect-of-authoring is identified by an IRI, which appears in the document as an attribute rif:dialect on the root element (for WD2, until we figure out extensibility)

Abstract Syntax Mechanism

Christian: Issues from yesterday; syntaxt questions about triangle
... Shows summary from yesterday
... Need PS and XS
... Need mapping between XS and PS

Harold: Shows mapping table

<ChrisW> Christian dropped Gary

<GaryHallmark> but I bounced back

<sandro> Harold: okay to have table from PS to XML, in WD2

Michael: Make abstract syntax more abstract

<sandro> MK: I'd like to change the constant syntax in PR to Const(...) or something.

<sandro> DR: maybe uniterm goes to Uniterm(op arg arg arg)

Axel: Why do we want abstract syntax

Christian: Which options require many changes wrt draft?

Harold: option 1 requires most changes
... option 3 is easy
... table already exists

<GaryHallmark> harold, is your table online or in email?

Michael: two is easiest
... One and three are the same
... We want a structural model
... Structural model was shown by Christian for illustration

Christian: Do we want also diagrams

Sandro: Diagram is only editorial work

Christian: diagrams are for illustrations

Sandro; How is head distinguished from body in presentation syntax in the table

Jos: Can be figured out in document

<sandro> "Structural Model Diagram"

<sandro> Option 1: AS as interlingua beetween PS & XML -- no prefer

<sandro> Option 2: PS++ and Direct Mapping -- no prefer

Option 2: PS++ and direct Mapping - one

<sandro> Option 3: 1 _ diagreams

<sandro> Option 3: 1 + diagrams == 2 people prefer

Option 4: Opt 2 + diagram: 9 prefer

<sandro> Option 4. 2 + diagrams = 9 prefer

<sandro> PROPOSED: We will use Presentation Syntax, with minor changed, with a mapping table to the XML syntax, with structural model diagrams. In WD2 the diagrams are "for illustration".

<sandro> MK: Let's not mention normativity in this draft.

Sandro: Seperate diagrams from question about presentation syntax

<sandro> PROPOSED: We will use Presentation Syntax, with minor changes, with a mapping table to the XML syntax.

<sandro> RESOLVED: We will use Presentation Syntax, with minor changes, with a mapping table to the XML syntax.

<sandro> PROPOSED: BLD WD2 will have structural model diagrams (which look like UML).

<sandro> RESOLVED: BLD WD2 will have structural model diagrams (which look like UML).

Christian: Do we include ASN version in the document

Axel: Currently it is enough to have the structural model diagrams

<GaryHallmark> -1 for ASN: it's not a standard (is it?) and would be the 4th way to present the syntax

Harold: We just simplified things, so omitted Abstract EBNF (as the intermediate language in the translation table) as well as ASN06 and 07

<PaulaP> +1 to Gary's comment...and Axel's

<josb> +1

<sandro> PROPOSED: Remove ASN from BLD WD2.

Christian: Our diagrams are only UML like but not really correct UML

Harold: ASN is not expressive enough
... that was the reason for introducing AEBNF

Dave: Our ambition is to have a clear UML meta model in WD2

Christian: We currently only have illustrative diagram
... currentl diagram is not a meta model
... We must be very careful in the wording in the document

Chris: We use UML
... not MOF

<Harold> The current cautionary note is "The above abstract syntax can be illustrated with a UML diagram, as shown below."

<sandro> Christian: Large label, "THIS IS UML NOT MOF."

Dave: Diagram is not equivalent to the syntax

Christian: Does somebody want to have ASN as well?

Bob: It is confusing to have all these representations

Dave: +1 for Axel and Bob

<sandro> RESOLVED: Remove ASN from BLD WD2.

<ChrisW> scribe: Michael Kifer

<ChrisW> scribenick: MichaelKifer

discussion of structural model of rules

<sandro> PROPOSED: change structural model so that Forall, Implies, and Atomic are three parallel subclasses of Rule.

<sandro> csma: to resolve issues about extensibility and ground facts. ground facts don't need to be in a forall.

csma re-proposed a UML diagram where ground clauses are not under Forall

<sandro> csma: simplifies BNF, too.

Also proposes to hang metadata off of Rule

<sandro> PROPOSED: For WD2, change structural model so that Forall, Implies, and Atomic are three parallel subclasses of Rule (shown on Christian;s diagram labeled "BLD Rule: alternative")

<Harold> PROPOSED: For WD2, change structural model so that Forall, Implies, and Atomic are three parallel subclasses of RULE (shown on Christian;s diagram labeled "BLD Rule: alternative")

<sandro> Prefers current SM - 0

<sandro> prefers suggests SM - 8

<GaryHallmark> the proposed change allows forall(forall(...))

<ChrisW> yes

<sandro> RESOLVED: For WD2, change structural model so that Forall, Implies, and Atomic are three parallel subclasses of RULE (as shown on Christian;s diagram labeled "BLD Rule: alternative")

<ChrisW> ACTION: Christian to update diagram in BLD draft [recorded in http://www.w3.org/2007/09/28-rif-minutes.html#action03]

<rifbot> Created ACTION-355 - Update diagram in BLD draft [on Christian de Sainte Marie - due 2007-10-05].

BLD Publication Timeline

<sandro> OCT 12 -- Frozen ED of WD2

<sandro> OCT 12 -- Reviews

<sandro> OCT 26 -- Freeze

<GaryHallmark> gotta run, folks. nice job tying up the XML syntax issues. "see" you Tuesday.

<DaveReynolds> ScribeNick: DaveReynolds

<scribe> Scribe: Dave Reynolds

BLD Comments about Primitive Types

Discussion on newer primitive types in the current BLD draft that received some comments

ChrisW: shows slide of these - rif:local, rif:text, rdf:XMLiteral

Michael: rif:local is constant which is local to a rule set
... in current draft no distinction to rif:iri because don't have modules, but once have modules the difference will be clearer

ChrisW: what is rif:text?

Jos: it is a literal we proposed to be equivalent to plain literals with language types in RDF, currently only in RDF section but will be added to the main text for next WD

ChrisW: what about rdf:XMLLiteral?

Michael: just a small fix was needed in text, done

csma: what are the consequences of this, is it an implementation burden?

[Discussion on this - if you want an xml literal you need something like this, we are just reusing the RDF approach]

Next F2F meetings

csma: closing data for room block booking for F2F8 is Oct 3

ChrisW: if in doubt, book it
... what about F2F9

Paris and Ireland mentioned as possibilities

It will depend on the dates and the dates depend on the future of the WG, probably early 2008 (around Feb)

Future of the Working Group

ChrisW: WG is chartered to end of Nov, what happens after that..
... Possibilities (1) we ask W3C for an extension

csma: for what puprose and for how long?

Phases: WD, Last Call WD (4-12 weeks), Candidate Rec (CR = call for implementations, time depends on implementations), Proposed Rec (PR = W3C member orgs vote on it, largely pro forma, 4-6 weeks), Rec

ChrisW: Possibilities are ...

(1) terminate

(2) extend (n months)

(3) recharter

Sandro: termination is the default
... extension formally is at the discussion of the director but in practice Sandro asks the management committee which might lead to dialogue with us
... recharter requires going back out to the whole membership

No one argued for option other than (2) extend

ChrisW: to do that we need reasons and new schedule and reasons we think we can make it

csma: preference to ask for short extension (6m?) to aim to enter LC for BLD
... then will know whether we are going somewhere or not and will then be able to put together realistic schedule for PRD and extension mechanism etc
... then we either ask for second extension to finish BLD or longer one to cover PRD etc

Sandro: we give ourselves 6m to figure whether we can indeed tie business rules in
... so we need enough work done on PRD to know how they fit together and what that means, they don't need to be at public working draft
... one of the requirements for RIF is extensibility and don't want to go to last call untill have some answer to that

ChrisW: is 6m to do this is feasible?

Jos: charter also asks us to take OWL compatiblity seriously, and we would need to get concensus on that

Michael: also wants module mechanism

So list of requirements for getting BLD to LC are:

- proven extensibility

- OWL compatibility

- Modules

- builtins

- conformance

- engine definition (i.e. need entailment definition and incusion/modules but NOT query language or API)

- UCR should go to LC

- test cases would be good

- extensibility mechanism rather than "proven" extensibility!

Sandro: charter defines what we have to say about extensibility, if someone asks how we would go a given extension we have to either indicate how to do this or why the extension is not necessary for rule interchange

Axel: arch and extensility sort of the same thing, so we need another one or two examples and how relates to BLD

csma: hence PRD

Sandro: would like so see Datalog and FO dialects
... as examples of how to do extensibility

Michael:

Axel agrees to take on some of Arch edit with Sandro but wants to talk about timeline

ChrisW: editor's draft by next F2F?

Axel: if we can just trash the unnecessary bits and do the minimum then OK

csma: if we work on that then we'll have a better idea of the timescale for extensibility which is why a short 6m extension is sufficient to derisk the following schedule

ChrisW: adds "- Arch to LC" to the list of goals of the extension
... concerned about having a whole other dialect on the path to extensibility, doesn't want that on critical path to BLD LC, a sufficient Arch LC would be good enough

Sandro: strawman/example dialects sufficient, not standard dialect

cmsa: in the first stage the PRD would be just a strawman/example

<sandro> I want Datalog and FOL as example/straw dialects. PRD can be an example dialect OR a standard.

ChrisW: be clear in minutes - that we agree that a second standard dialect is not a necessary requirement for meeting the extensibility requirement from charter

<sandro> Chris: I want it recorded that we agree that The Extensibility requirement from the charter is NOT contingent on having a second (real) dialect.

What about "OWL compatibility"?

csma: not necessary part of BLD can be separate document on different timescale

Sandro: can't get out of CR without that doc, it would be a mistake to have that lag too much behind

Jos: would actually prefer the OWL compatibility (and RDF) in a separate document

ChrisW: is that other document another dialect? the combination part extends the semantics, isn't that another dialect?

Michael: less clear now on exactly what the combination semantics implies

Discussion on whether need the OWL compatibility doc before taking BLD to last call

<sandro> PROPOSED: The OWL Compatibility text will proceed to Last Call in sync with BLD.

<sandro> RESOLVED: The OWL Compatibility text will proceed to Last Call in sync with BLD.

<sandro> PROPOSED: No Modules! (mk out of room)

builtins - yes we need these

conformance? - yes need this

entailment? yes but we already have that

test cases?

ChrisW: would need someone to act as test case maintainer

Sandro: the test cases need not be a big deal

ChrisW: the test cases need to be correlated with the issues in the design, especially on a language with inferential capability

Adrian, Sandro volunteered to help with test cases (Sandro thought Gary might also have an interest in helping)

csma: data type extensibility is an example of thing that would need test cases

modules? just missing and intend to add or is it critical path for BLD?

Michael: needed whenever with have some form of include, what OWL did is not good enough for rules because rules interfere with each other a lot

Paula: offers to propose module system for BLD

Michael: there are already some such proposals in existence (e.g. from Rome(?) group)
... well more important that some features we already have

Sandro: lists are also mentioned in the charter

ChrisW: so is a 6m extension to get to start of LC the right thing to ask for

DaveR: what about extension to end of LC so can get external feedback?

Sandro: sees extension more about internal, can we get to agreement
... a test is how much of WG can come to F2F and do the work through this extension

<sandro> sense of group (unanamous) ask for 6 months extension..... (with some fuzziness :-) some sense of maybe ask for more.

strawpoll on 6m extension? no one opposed, almost everyone in favour

<sandro> scribeNick: StellaMitchell

RDF-RIF compatibility - embed or combine: which is normative

jos: I have 2 use cases in mind, re: rdf compatibility
... 1. RIF rules + RDF data

2. RIF rules with RDFS data model

jos: (giving example, rdf graph that shows that rdf data and rdfs data model are similar)
... RDF semantics - semantics is defined in a similar way to RIF
... : RDF semantics defines 4 normative entailment regimes
... I will describe 2 of them: simple and RDFS
... simple doesn't take into account any special vocabulary
... rdfs takes into account rdfs vocabulary
... (describing blank nodes)
... so, the question is, given these entailments, how do we address the 2 use cases?
... at syntactic level, you have a RIF ruleset R and an RDF graph S, and the combination <R,C>
... then we have to define at the semantic level how those 2 things interact
... example: if x is student then x is poor
... need to have a way to relate above rule to an RDF graph
... at syntactic level, easy mapping between RDF triples and RIF frames
... so writing above example as: isPoor(?x) :- x[rdf:type --> student]
... but need to be precise for the specification
... so, interpret the RIF ruleset R with RIF interpretation, and the RDF graph S with the RDF interpretation
... and add conditions on the interpreations
... if you use rdfs data in your rules, I think you must use the rdfs semantics
... now that we have semantics, we can specify entailment in the usual way through model inclusion
... and we can define it for each of the RDF types of entailment
... the receiver of the RIF rules that refer to an RDFS data model, you want to be able to process the rules (querying, entailment checking)
... and in order to do that, you must have an embedding so that you can check entailment with your rule engine
... so, we need to be able to check for satisfiability
... I defined a translation function to allow that to be done

chrisw: in the example rule, there is no entailment on the graph?

jos: right

michaelk: I now understand what Jos wants to do now, and I now
... believe that combined semantics is required and the embedding is not
... I now understand: there is a rule lang that works with rdf data, and another rule lang with diff syntax and also works with rdf data
... so, I think we need a dialect to do this
... an RDF dialect
... to specify the dialect, we need to define syntax and semantics
... note that the data is not exchanged via RIF; it has its own exchange language

axel: I think RDF data should stay in it's RDF form and not be embedded

MK: right
... so, in conclusion, I think we do not need the embedding
... (just the combined semantics)
... (I am confused about it - about why we mignt need embedding)

chrisw: what if we have a ground entailment?
... what if you have non-ground entailment that cannot be expressed in RDF?
... it goes into the combination
... (entailments that cannot be encoded in a graph)
... what about ground frames in ruleset?
... what is the correspondence between that and RDF graph?

jos: it would be in entailed graph and entailed condition also

daver: I want to record that we need a way to treat RDF as data

- DRAFT -

RIF F2F8 - 28 Sept 2007

28 Sep 2007

Attendees

Contents