(No activity for 10 minutes)

(Scribe changed to Michael Kifer)

Sandro Hawke: last call means we are done

Sandro Hawke: after DTB is at last call, we can go for CR (candidate implementation). After that, we are not supposed to make any substantive changes to BLD.

At this point, we call for implementation

Christian de Sainte Marie: "Substantive" changes are not allowed to be made after a call for implementations.

Sandro/Jos/csma: Example: changing the presentation syntax is a substantive change.

(No activity for 7 minutes)

ACTION: jos add explanatory text to SWC and reply to http://lists.w3.org/Archives/Public/public-rif-comments/2008May/0000.html asking if it explains the matter sufficiently.

ACTION: jdebruij2add explanatory text to SWC and reply to http://lists.w3.org/Archives/Public/public-rif-comments/2008May/0000.html asking if it explains the matter sufficiently.

ACTION: jdebruij2 add explanatory text to SWC and reply to http://lists.w3.org/Archives/Public/public-rif-comments/2008May/0000.html asking if it explains the matter sufficiently. due wednesday

discussion of Dan C's comments about use/mention of IRIs in RIF. Jos will respond to him.

discussion of Dan C's comment on the fact that BLD does not allow the same symbol to be used in different contexts. This will be a problem for merging of rules (one set may have a predicate as a 2-ary thing and in another as a 3-ary thing, for example).

Decided (guest): to keep discussing this issue.

(No activity for 9 minutes)

(No activity for 10 minutes)

ACTION: Jos to add section to SWC which guides people familiar with W3C Semantic Web specs about the surprising differences, eg rif:iri - due Wednesday

ACTION: jdebruij2 to add section to SWC which guides people familiar with W3C Semantic Web specs about the surprising differences, eg rif:iri - due Wednesday

Discussion of Jeremy's comments about rif:text, rif:iri. Decided: will add clarifications.

(No activity for 13 minutes)

(No activity for 9 minutes)

discussion of Dave R's comments. Most are editorial, which weren't discussed. Others will be discussed elsewhere (eg, in the FLD/BLD parts of the agenda).

(No activity for 31 minutes)

(No activity for 6 minutes)

(Scribe changed to Harold Boley)

Implementations

Gary Hallmark: ORACLE UCR Use Case 1

Conclusion of rule uses a frame.

Christian de Sainte Marie: Modeled as a frame only because a little easier?

Gary Hallmark: OBR's best mapping of BLD goes to a frame because of its bean notion.

Harold Boley: Use a frame as a conjunction?

Gary Hallmark: Can also use Group to attach conclusion results.

... splitting the And in the then part into two rules.

Jos de Bruijn: For only constants as slot fillers, frames could be used.

Christian de Sainte Marie: Why nesting of <And> <formula> <And>?

Gary Hallmark: Because of the principles of our general XML generator. Could be optimized away for the special case of BLD.

Sandro Hawke: What about the other direction?

Gary Hallmark: Yes. But will need to be worked out.

... We avoid showing durations to end users.

... For ex., days-between in OBR is not exposed to users.

Christian de Sainte Marie: Implementations should have access to such built-ins.

Michael Kifer: rif:new should really be rif:local (because rif:new is not unique).

... If it's a generator, it should be local.

... We need a standard way for handling skolems (via rif:local).

... Problem: The same symbol cannot be used in different contexts.

... Could change the definition of well-formedness. Not allow these skolems in equalities.

Gary Hallmark: Round-tripping with OBR would be a problem.

Sandro Hawke: Sent email about this last week.

Christian de Sainte Marie: 'Hidden conjunction" forbidden?

... multiple slots of a frame in the head.

... normally there is no conjunction in the head.

Michael Kifer: Right, maybe we should allow conjunction in the head, like disjunction in the body.

Christian de Sainte Marie: Can we change the document?

Michael Kifer: Cannot guarantee change will not introduce errors.

PROPOSED: BLD will include Conjunction in the rule head

PROPOSED: BLD will include Conjunction in the rule head (the "then" part)

0

RESOLVED: BLD will include Conjunction in the rule head (the "then" part)

Harold Boley: May increase the burdon on BLD implementers to claim they have a direct (without rewriting) implementation of BLD.

DTB review & publication

Axel Polleres: Symbol Spaces

Sandro Hawke: Maybe first motivate them before going into the mat.

s/ mat./ math./ (failed)

Sandro Hawke: The doc now doesn't use Curies?

Axel Polleres: It does (now).

Sandro Hawke: Keep Fcts and Preds in the same namespace?

Axel Polleres: builtin-functions vs. builtin-predicates.

... different semantics.

Jos de Bruijn: But user does not see this.

PROPOSED: func: and pred: collapse to one, http:/www.w3.org/2007/rif-builtin#

Axel Polleres: Right.

Christian de Sainte Marie: What's the drawback of having two namespaces?

Jos de Bruijn: It's just more (unnecessary) namespaces.

Sandro Hawke: You have to remember both.

Axel Polleres: If we added a type Boolean, then we could consider collapsing the Fct and Pred namespaces.

Jos de Bruijn: Did we not decide that we will not have to versions (Fct and Pred) of the same builtin?

PROPOSED: keep the two namespaces, pred: and func: ....

Igor Mozetic: Whenever we tried to 'simplify' things in this way, it turned out there were later some complications. So we should keep the separation.

PROPOSED: remove language about all the subtypes of xsf:string

PROPOSED: remove language about all the subtypes of xsd:string being required

RESOLVED: remove language about all the subtypes of xsd:string being required

PROPOSED: instead of all-subtypes-of-decimal, have just Decimal, Integer, Long, .....

(No activity for 20 minutes)

(No activity for 33 minutes)

(Scribe changed to Adrian Paschke)

Continue DTB discussion

Axel Polleres: Goal for outsourcing into a seperate document to define the supported datatypes

Axel Polleres: Current DTB says it defines the supported BLD datatypes

Chris Welty: My understanding was that it is common to all RIF dialects

Sandro Hawke: Each dialect will have a subset of the DTB datatypes and builtins

Michael Kifer: or a superset

Sandro Hawke: DTB has to grow if new datatypes are needed in standardized dialects

Axel Polleres: it was moved / copied from FLD

Michael Kifer: yes, it has been copied from FLD to DTB

Chris Welty: It is a maintenance problem to add all new standard datatypes and builtins to DTB?

Sandro Hawke: only datatypes and builtins from standardize RIF dialects

Chris Welty: we agreed if a standard dialect needs a datatype or builtin function it needs to be in DTB

Michael Kifer: dialects may support additional datatypes

Jos de Bruijn: we only talk about standardized dialects

Michael Kifer: we would have mandatory and optional datatypes

Chris Welty: put it in core

Harold Boley: DTP is in some sense parallel to FLD

Michael Kifer: Organize built-ins in groups in DTB

Michael Kifer: let's organize them in groups and link to them from BLD

Sandro Hawke: organize them in levels, e.g. numeric built-ins level 1, level 2

PROPOSED: DTB will provide the menu of datatypes and builtins which diallect dialections can use, by reference, when they state which datatypes and builtins must be supported by implementations.

Michael Kifer: change to ... built-in predicated required by the RIF BLD

PROPOSED: DTB will provide the menu of datatypes and builtins which diallects can use, by reference, when they state which datatypes and builtins must be supported by implementations.

PROPOSED: DTB will provide the menu of datatypes and builtins which dialects can use, by reference, when they state which datatypes and builtins must be supported by implementations.

+1

RESOLVED: DTB will provide the menu of datatypes and builtins which dialects can use, by reference, when they state which datatypes and builtins must be supported by implementations.

ACTION: axel to edit DTB to reflect its changed role with regard to DTB (eg in the Abstract)

(No activity for 6 minutes)

Adrian Paschke: We need durations to implement some of the use cases

PROPOSED: add year-month and day-time duration, but NOT duration, to BLD.

PROPOSED: add year-month and day-time duration, but NOT duration, to BLD, as in http://www.w3.org/TR/xquery-operators/#dt-yearMonthDuration

PROPOSED: add year-month and day-time duration, but NOT duration, to BLD (and of course DTB), as in http://www.w3.org/TR/xquery-operators/#dt-yearMonthDuration

PROPOSED: add xs:dayTimeDuration and xs:yearMonthDuration, but NOT duration, to BLD (and of course DTB), as in http://www.w3.org/TR/xquery-operators/#dt-yearMonthDuration

PROPOSED: add xs:dayTimeDuration and xs:yearMonthDuration, but NOT duration, to those required in BLD (and of course DTB), as in http://www.w3.org/TR/xquery-operators/#dt-yearMonthDuration

RESOLVED: add xs:dayTimeDuration and xs:yearMonthDuration, but NOT duration, to those required in BLD (and of course DTB), as in http://www.w3.org/TR/xquery-operators/#dt-yearMonthDuration

ACTION: axel to add the new duration subtypes to DTB

ACTION: kifer to make sure BLD includes the appropriate normative reference to DTB to reflect the inclusion of the duration subtypes

Chris Welty: Gary's numeric remark

Gary Hallmark: less_than_or_equal ...

Axel Polleres: you typically have general builtins such as > < <= ...

Gary Hallmark: I only need numeric_greater_than_or_equal ... less_than_or_equal

Chris Welty: short cuts such as >= <= !=

PROPOSED: add builtin predicates to BLD and DTB: <= >= and != for numeric values (they amount to shortcuts, to avoid disjunction).

+1

PROPOSED: add builtin predicates to BLD and DTB: pred:numeric-less-or-equal, pred:numberic-greater-or-equal, pred:numberic-not-equal (they amount to shortcuts, to avoid disjunction).

+1

RESOLVED: add builtin predicates to BLD and DTB: pred:numeric-less-or-equal, pred:numberic-greater-or-equal, pred:numberic-not-equal (they amount to shortcuts, to avoid disjunction).

Sandro Hawke: have an editor from OWL and RIF to discuss about rif:text or using a owl datatype

Christian de Sainte Marie: BLD requires rif:text, so we have a dependency to a document which does not exist if me move it to another document

Chris Welty: keep in DTB

Harold Boley: add an editors note about it

ACTION: Harold to add AT RISK editor's note in BLD explaining that the IRI identifying rif:text might change.

Axel Polleres: Casts from rif:iri as defined in XML Schema

ACTION: Chris to open issue on casts to/from rif:iri

Jos de Bruijn: cast functions are not defined, yet

Axel Polleres: see section 4.3

ACTION: Axel to change editor's note on casting rif:iri to normal open-issue style, link to new issue on it.

ACTION: Axel to convert text about concat2, etc, into an editor's note about how the handling of arities is a strawman proposal not yet agreed upon by WG.

ACTION: axel comment out DTB 4.7 or otherwise make sure it doesn't end up in BLD

(No activity for 5 minutes)

PROPOSED: Publish DTB as a FPWD once changes decided so far today are made (and reviewed by ...someone...)

PROPOSED: Publish DTB as a FPWD once changes decided so far today are made (and reviewed by ...someone...)

PROPOSED: Publish DTB as a FPWD once changes decided so far today are made (and reviewed by Chris)

+1 (REWERSE)

RESOLVED: Publish DTB as a FPWD once changes decided so far today are made (and reviewed by Chris)

(No activity for 10 minutes)

(Scribe changed to Igor Mozetic)

striping, typed-tagged XML aka Rigid RDF

we have nearly full-striped syntax, why not move further?

pro: small step, gives RDF compatibility

pro: fallback mechanism is RIF

pro: more implementers can support

con: even more verbose

Christian de Sainte Marie: main objective is not fully-stiped, but RDF compatible synta

con: "marketing" issue (some don't want RDF)

pro: "marketing" issue (if there is no dependency, then RDF compatibility is a plus)

Christian de Sainte Marie: for Alex - changing rigid RDF to typed-tagged-XML would solve his opposition

dependency on RDF namespace is _not_ RDF dependency

Sandro pro: it is self describing

Sandro Hawke: self-describing = deserialization back into "objects"

proposed changes by Sandro:

... add rdf:parseType=Collection to args

Christian de Sainte Marie: this proposal breaks full striping but we need RDF compatibility

... 2) add name under Var

... change from not-striped to striped

... 3) add value role under Const

Michael Kifer: issue is with symbolspace that are not datatypes

Michael Kifer: RDF friendliness brings semantics into syntax

Jos de Bruijn: we need to specify order in the syntax anyway

... 4) rif:iri inside Const is serialized differently

... add 4) uses native RDF support

... add 4) rif:iri and rif:text would disapear from XML serialization

Sandro Hawke: the only change is in the serialization, not in PS

Christian de Sainte Marie: an RDF parser will get RDF triples, not rules

Michael Kifer: is affraid that RDF semantics will be assumed

Christian de Sainte Marie: if this change is zero-cost it is advantageous for the community

... since people will get RDF triples for free and do whatever they want

... Sandro: 5) role tags may have to be in alphabetical order

Sandro Hawke: one can load RIF doc into triple store and extract rules by querying it

changes would require the following in BLD document:

translation tables, examples, XML schema

(Scribe changed to Gary Hallmark)

Conformance

Michael Kifer: must preserve entailments

Christian de Sainte Marie: but editors don't entail anything

Chris Welty: semantic v. syntax

Michael Kifer: editor doesn't actually DO anything

Sandro Hawke: e.g. biz rule editor imports rif into GUI

Jos de Bruijn: syntax checkers need to validate syntax

Michael Kifer: bijective mapping between 2 languages

... entailments include datatype conformance

Sandro Hawke: what if we encounter a datatype not in BLD?

... that would be an extension of BLD

... syntax check may pass

Jos de Bruijn: rule processor has set of datatypes, and can talk about differences w.r.t. DTB

Sandro Hawke: how to include xs:int in a rif document

... should it convert to xs:decimal, or ignore, or warn?

... should warn or reject

Jos de Bruijn: if conversion is lossless, then it is supported

Michael Kifer: must be in DTB to have a semantics

in the above, "datatype" also includes associated builtins

Michael Kifer: could separate syntactic and semantic conformance

... syntactic subset can be larger

Sandro Hawke: hopes entire languages are translated to RIF, implying many extensions

... allows roundtripping

Christian de Sainte Marie: must be able to add (non-std) extensions to make RIF usable

Michael Kifer: don't require all datatypes are listed in DTB to have a valid RIF document

Christian de Sainte Marie: any other notions of conformance?

Jos de Bruijn: basic notion should be entailment

... first, a RIF consistency check (has a model)

Christian de Sainte Marie: but I can have an inconsistent RIF document

Jos de Bruijn: datatype conformance should be like OWL. Must support DTB, reject others

... for semantic conformance

Michael Kifer: distinguish producers from consumers

Christian de Sainte Marie: given agreement on datatypes (even if not in DTB), entailments are preserved

Michael Kifer: what does it mean to agree?

Jos de Bruijn: must decide what to do about datatypes not in DTB

Chris Welty: conformance defined for a single RIF processor, not for a communicating pair

Michael Kifer: for producer, must be mapping into RIF, and have right entailments

... for consumer, must reject datatypes you do not understand (which must not be in DTB)

(No activity for 8 minutes)

much discussion formalizing the conformance statement...

Dave Reynolds: must a consumer be a complete BLD implementation?

Sandro Hawke: yes

Dave Reynolds: concerned about equality

Christian de Sainte Marie: equality in head may be "at risk"

Dave Reynolds: used to have a notion of BLD being a superset

... a conformant impl could be a subset

Christian de Sainte Marie: is this the notion of profiles?

Christian de Sainte Marie: maybe we'll need profiles since we no longer have CORE

Christian de Sainte Marie: maybe solution is to remove equality from BLD

Sandro Hawke: if we need a dialect between CORE and BLD, we'll create one (but I hope not)

... e.g. mini-BLD

Christian de Sainte Marie: if we don't get implementations, we'll have to revisit

Christian de Sainte Marie: does marking some hard things as "at risk" satisfy Dave?

Dave Reynolds: yes

Chris Welty: maybe the conformance statement is "at risk"

Michael Kifer: could have levels of conformance, and lower the bar as needed

Sandro Hawke: let's talk about syntax extensibility

... must reject syntax you don't understand

... is somewhat counter to the XML philosophy

... but can't ignore NOT, e.g.

... and we don't require "fallback" processing

Naming

Sandro Hawke: doesn't like upper/lower

Christian de Sainte Marie: in PRD, object/class and subclass/class

Christian de Sainte Marie: wants different tags for different content

... makes PS->XML mapping easier

... because it is not context dependent

Sandro Hawke: sub/super for SubClass

Harold Boley: instance/class for Member

Hassan, I though you don't like abbrevs

ACTION: Harold update BLD to change lower/upper to instance/class and sub/super.

Chris Welty: doesn't like '->' in frames

... too much like implication

... also -> used for named args

Christian de Sainte Marie: but PS is tomorrow

Christian de Sainte Marie: prefer attribute instead of key

... for the frame case

Harold Boley: principle of context-independent role names not maintainable in FLD

Hassan Aït-Kaci: XML tags should be independent of BNF

... distinguish grammar from language

... former is not unique

... in prototype, had to modify EBNF for jacc, and this ripples through the XML mapping if they are linked

Harold Boley: many XML tags have a different PS token, e.g. ?/Var, ^^/Const

(Scribe changed to Andreas Harth)

Agenda review

this session: presentation syntax, especially shortcuts

Christian de Sainte Marie: Issue 56

Jos de Bruijn: which shortcuts to define

Axel Polleres: sent out proposal yesterday about grammar

Presentation syntax

Axel Polleres: do we want to have string lang tag? his proposal is to use grammar from sparql spec

Jos de Bruijn: just use absolute IRIs not relative IRIRefs

Jos de Bruijn: in the definition, all w3c standards have full IRIs in their spec

Chris Welty: rif doesn't need to know about curis

... do preprocessing to expand iris

Axel Polleres: basically just added the lang tag, ok to use iri, ok to use prefix def in presentation syntax

... still open are string and escaping, we should use the sparql syntax here as well

Axel Polleres: syntax allows to only write the prefix, which is just resolved to the iri of the prefix

Christian de Sainte Marie: decision to make: does it make sense, whether to use iri or iriref, how to address escaping

... any objections?

Michael Kifer: not use anglebrackets

Axel Polleres: we addressed that in the last telecon, just added last line

Michael Kifer: problem is in one place it's really an iri, in other place it's just a marker

Mike Dean: should have ways to use curis and iris

Christian de Sainte Marie: issue is string^^<IRI>

... for const

Michael Kifer: here, it's just a symbol that looks like a iri but it's just a constant

Christian de Sainte Marie: it's mentioning the iri but not using it

Michael Kifer: symbol space is not identified by iri, but just a symbol

Christian de Sainte Marie: you want a different syntax for the different roles of an iri?

Axel Polleres: do we open a can of worms here? for sake of readablilty, i'd buy the conceptual ambiguity

Axel Polleres: with current proposal we're compatible with n3 syntax

Michael Kifer: the aliases are not required to be iris

Christian de Sainte Marie: need to change it either in bld or here

Christian de Sainte Marie: must the aliases be iris or not?

Michael Kifer: curis could be still too long

PROPOSED: remove aliases for datatypes in BLD

PROPOSED: remove aliases for symbol space identifiers in BLD

PROPOSED: remove aliases for symbol space identifiers in RIF

Sandro Hawke: does that leave us with this syntax? still possible that say two datatype iris are equal?

Christian de Sainte Marie: any more questions?

RESOLVED: remove aliases for symbol space identifiers in RIF