yes

scribe Axel Pollere

<ChrisW> Scribe: AxelPolleres

scribenick AxelPolleres

<sandro> scribenick: AxelPolleres

<ChrisW> http://lists.w3.org/Archives/Public/public-rif-wg/2008Mar/att-0113/25-rif-minutes.html

ChrisW: we have to approve minutes from last week, objections?

<ChrisW> PROPOSED: accept March 25 telecon minutes

<ChrisW> RESOLVED: accept March 25 telecon minutes

no objections, minutes accepted.

ChrisW: One amendment to the agenda: Discuss structure of BLD document, to be added to pub-plan section of the agenda.

F2F10

<johnhall> zakim p27 is me

News for f2f?

<johnhall> zakim.mute me

ChrisW: we should get f2f registration fomr out beginning of may.

Action review

ChrisW: close form around May 10th

Axel: No news, all data is online on the f2f page.

Action review

<sandro> yes

ChrisW: Harols now maintaining XSD.

Action ??? continued.

ChrisW: Jos to review metadata in BLD
... action http://www.w3.org/2005/rules/wg/track/actions/456

<scribe> ... pending discussion

Action 455 completed

Action 454 continued

Action 453 completed

Action 452 continued

ChrisW: Adrian, when do we have the next ucr version.

AdrianP: in two weeks.

Action 443 completed

Action 442 completed

<AdrianP> http://www.w3.org/2005/rules/wiki/Category:Test_Case

Action 440 pending discussion

<AdrianP> and also http://www.w3.org/2005/rules/wg/wiki/Arch/Test_Cases

Action 439 continued

Action 435 continued

Action 458 continued

Action 433 will be discussed today

Liason

<AdrianP> I'm in contact with Hugh Wallis, XBRL Director of Technical Standards

Action 428 change to "Stabilize DTB" and change date to next wednesday (april 9th)

Liaison:

<AdrianP> XBRL Formula Working Group relevant for RIF

Adrian reports about XBRL

<AdrianP> Hugh Wallis will find a liaison partner

(adrian, can you type in what you said?)

josb: OWL people will discuss at their coming f2f the RIF-OWL compatibility document.

Issues Review

http://www.w3.org/2005/rules/wg/track/issues/open

ChrisW: Would like next week to go through Phase2-requirements issues and maybe mark what we won't address.
... some of these issues are actually addressed already.
... we can clos some of them and mark others which we won't resolve anyway.
... will write that up in the next days.
... critical path issues
... how are we going to address these things?
... current schedule asks for last call by end of may.
... jos you had a proposal for importing rulesets issues?

josb: we have to choose an option directive or import clause.

(jos, is rthere a mail, can you paste the link?)

josb: we have rthe notion for rif:local, in import we have to rename the local constants.

ChrisW: is there a proposal for that?

josb: only what I just sketched.

Harold: We have worked on nested rule sets. Will come back to that later.
... will send a pointer to that topic.

ChrisW: do I undertand right that you wrap metadata/rules?
... This is in the latest BLD?

Harold: yes in the latest version of the grammar.

<JamesOwen> Is there a question on whether we should or should NOT allow recursive rulesets?

<Harold> Ruleset ::= 'Ruleset' IRIMETA? '(' (RULE | Ruleset)* ')'

Sandro: that seems orthogonal to imports.

<Harold> Ruleset ::= 'Ruleset' IRIMETA? '(' (RULE | import(Ruleset))* ')'

<MichaelKifer> what does it have to do with recursion? this is just a grammar

<JamesOwen> For Goal-Oriented type programming, you must have recursive rulesets

ChrisW: jos raised trhe issue on dealing with local names on imports, any proposals on that?

<MichaelKifer> this is unrelated to recursive rules

ChrisW: Jos can you take an action to flash out a proposal?

<JamesOwen> recursive - meaning that a ruleset calls a ruleset that calls itself

DaveR: Wasn't there previously a proposal on modules which could capture thsat?

<JamesOwen> maybe

MichaelK: I don't think we have time left for modules.

<sandro> JamesOwen, this is abot having a ruleset physically or logically INSIDE another ruleset.

ChrisW: I think having some import notion is critical path. What's the diff between modules and imports?

<DaveReynolds> +1 some form of import is needed

<JamesOwen> Correct - and that would be necessary for Goal-oriented rulebase programming

MichaelK: modules much more general, allows query on modules without complete import.

<sandro> mk: a module is more general than imports -- it's another KB, and you can issue queries to the KB, rather than importing the rules.

<PaulVincent> +1 on some form of "ruleset reference" is that is the same as "import"

ChrisW: How's that more general than imports?

MichaelK: you can represent/simulate imports with modules.
... all we need is the same semantics as "imports"

<Harold> Regarding local names, this issues comes up already when dealing with the *union* of two explicitly given Rulesets, not only when one of them is referenced indirectly through an 'import' statement.

Sandro: It sounds like you have something in mind which you can write up quickly.

<JamesOwen> In the insurance industry, a ruleset has to import a ruleset as opposed to just "calling" another ruleset

Sandro: would it make sense to write it down or discuss now?

MichaelK: don't know if I have enough time before final draft.

<Harold> James, I agree with your points.

ChrisW: Semantics you had in mind was basically like "copy" with renaming/changing local symbols somehow, yes?

josb: right.

MichaelK: modules more general.

<sandro> Chris: Would there be harm in starting with imports and later generalizing to modules.

ChrisW: couls modules be added later or are they interferring?

<Harold> The just "calling" aspect is now handled for builtins with 'External' calls. The "import" aspect is harder, since the rules (with local names) need be consolidated.

MichaelK: We could later on redefine the semantics of "imports" wrt. "modules"

<sandro> ACTION: jdebruij to propose a solution for Imports [recorded in http://www.w3.org/2008/04/01-rif-minutes.html#action01]

<trackbot-ng> Sorry, couldn't find user - jdebruij

<sandro> ACTION: jos to propose a solution for Imports [recorded in http://www.w3.org/2008/04/01-rif-minutes.html#action02]

<trackbot-ng> Sorry, amibiguous username (more than one match) - jos

<trackbot-ng> Try using a different identifier, such as family name or username (eg. jdebruij2, jderoo)

<sandro> ACTION: jdebruij2 to propose a solution for Imports [recorded in http://www.w3.org/2008/04/01-rif-minutes.html#action03]

<trackbot-ng> Created ACTION-459 - Propose a solution for Imports [on Jos de Bruijn - due 2008-04-08].

ChrisW: Can we give an action to Jos on writing up imports.

Josb: fine.

<sandro> mk: There's a solution -- Peer-to-peer knowledge bases -- from the Romans

Josb: I think michael has something like flora-2 modules in mind.

<JamesOwen> (Romans?)

ChrisW: deadline for action 459 next telecon.

<Harold> Maurizio Lenzerini's nice slides on Hyper: http://www.scs.carleton.ca/~diis/arise/workshop.html

ChrisW: Issue 34, extensibility of datatype support.

http://www.w3.org/2005/rules/wg/track/issues/34

Harold: still for previous point: we discussed differenct between external calls and modules.

(who spoke?)

<sandro> JamesOwen,

James: (can you type in what you just said?)

<AdrianP> and there are sometimes also distinctions between "include vs. import"

ChrisW: do we have a proposal about what extensibility actually means?
... one point was what to do when getting a datatype which you don't support?

<JamesOwen> we have two or three things going on right now. Extensibility is (I would think) a UML problem that we have to address in ruls

ChrisW: "just reject" would be one approach.

<josb> rejecting is the current approach, as far as I know

<DaveReynolds> +q

sandro: I was hoping we would fix this with fallbacks, but we didn't talk about it in the context of fallbacks yet.

<JamesOwen> An un-supported data type should throw an exception

sandro: e.g. fallbacks from one datatype to another.
... there are strategies which work in certain cases, not quite sure about general.
... fallbacks are triggered by presence of syntactic properties.

<AdrianP> for fall back we probably would need to define some default type casting rules

sandro: xs:int could be used as a kind of constant, instead of taking the datatype into account.
... I should probably take an action to solve issue 34.

ChrisW: should this go into DTB? Where does extensibility go?

<Harold> Let's take an example/uc: If you get a set but can only handle lists, you could try to represent sets as lists without duplicates in lexicographic order. However, set *unification* ist very different from set *unification*.

Sandro: I can take the action within 2 weeks.

DaveR: part of the reason why extensibility works in RDF is that non-understood parts are passed-through "as is"

<sandro> ACTION: sandro to propose solution to ISSUE-34 -- what do you do when you get a ruleset with data values and/or built-in types you don't know? [recorded in http://www.w3.org/2008/04/01-rif-minutes.html#action04]

<trackbot-ng> Created ACTION-460 - Propose solution to ISSUE-34 -- what do you do when you get a ruleset with data values and/or built-in types you don't know? [on Sandro Hawke - due 2008-04-08].

DaveR: can we have something like that in RIF?
... reject is the easy default. but we could also say it is an implementation issue

Issue 33:

Specification of data sources in RIF [CP]

Sandro: that's pretty close to imports.

ChrisW: not sure. (because beforehand translation to rif necessary)

AdrianP: could also be some query-builtin which gets data on from an external database.

<sandro> Sandro: it's kind of a paramaterized import --- attach this to your-local-whatever.

<AdrianP> building a constructive view over external data

ChrisW: I would like to agree to sandro, if we can treat it as imports, it should be easy, otherwise, hard.
... other discussion on that?

josb: we need to refer to RDF graphs and OWL ontologies.

<Harold> Jos, Yes, also we should consider RDF Named Graphs.

josb: not necessarily obligatory, but often needed.

<Harold> Named Graphs are like modules.

josb: first we need to include the references to those graphs/ontologies.

sandro: same as imports?

josb: not the same, because rdf graphs and ontologies are no rulesets.

sandro: you point is if the data/ontology doesn't tell you enough how to imprort, e.g. OWL DL vs OWL full import.

josb: yes, several possibilities.

ChrisW: in the reference statement you should mention the semantics for the import/combination as well?

<sandro> maybe these are flags you throw onto import.... <imports><Ruleset><location>http://.... or <imports><Ontology><variant>Full<...> .

josb: I was thinking of import through additional directives.

ChrisW: imports is a directive.
... can you do that in your proposal for imports?

<johnhall> Sorry, have to go to another meeting. Bye

sandro: for the user it should be the same, flags should be allowed and some defaults.

josb: that's possible, I would personally prefer separate tags.
... i can do the following: assume that "imports" is also used for RDF and OWL and flash out an additional flag for the import-semantics

<JamesOwen> Is this the UML Round Tripping?

chrisw: last CP issue: roundtripping (issue 26)
... anything specific?
... anyone object to close this?

sandro: I keep picturing this as a case for 3rd party extensibility.

<markproctor> without round tripping you get import only. so I think that round tripping is useful for the industry.

sandro: how can 3rd parties with dialects beyond BLD still use RIF as an exchange formats such that rules are sound-trippable importable and re-exportable.

<Hassan> I think metadata is adequate for this purpose

sandro: could be done by stuffing in custom metadata, probably.

<markproctor> round tripping also allows you to test the soundness of your parser.

<markproctor> if you can import and export something and the results are the same, you know things are working.

ChrisW: the fallback mechanism is a part of roundtripping.

<AdrianP> could be some kind of annotations as used e.g. in model transformations, refactoring

ChrisW: but there is additionally the medadata part (e.g. could be used for order of rules, etc.)

Sandro: we need some text maybe in UCR talking about the concept of roundtripping.

DaveR: if we say rif preserves nothing but the metadata, than we have to put it there.

ChrisW: anything that doesn't matter to the semantics, that might change, is not (?) a matter for roundtripping

sandro: OWL and RDF people would have waeker concerns about roundtripping than XML people, probably.

ChrisW: strawpoll on CP issues.

<josb> +-1

<sandro> STRAWPOLL: Addressing Roundtripping is critical path for BLD Last Call

<Harold> -1

<Hassan> -1 (roundtripping is like a unversal rule translator!)

<sandro> -1

<AdrianP> -1

<PaulVincent> 0

<IgorMozetic> -1

<DaveReynolds> 0

<josb> -1

0

<LeoraMorgenstern> .3

<ChrisW> -1

0 (don't know)

<LeoraMorgenstern> (That is, I do think it's important, but I also think it's an impossible task.)

<JamesOwen> +1

scribe: instead of "don't care"

<sandro> Chris: maybe the chairs will take this off the critical path, thanks.

<AdrianP> we could say that this can be handeled by test cases which implementer define

ChrisW: thinking about removing this from critical path.

Metadata

ChrisW: new syntax in BLD for metadata.

Harold: we found a simple twist to the EBNF by allowing nesting of rulesets.
... so we have only a single place where we can attach metadata.

DaveR: I would have thought the canonical case was attaching metadata to single rules.

<josb> +1 to Dave

<PaulVincent> Comment: Existing BRMS tools tend to apply metadata on a per rule basis...

<sandro> DaveReynolds: I don't see the advantage of forcing everyone to wrap a rule in a ruleset.

Harold: you can put a single rule in a ruleset.

<Hassan> Metadata should be allow at BOTH the ruleset and individual rule level

<josb> Why should we make things more complicated than they should be? Nesting of rule sets in BLD is a very bad idea.

Harold: attaching metadata to a ruleset which can also be a single rule.

<josb> we still want to assign identifiers to individual rules

MichaelK: think of just having a single tag for rulesets or rules to attach metadata.
... or anything else.
... with our new proposal we can now use rulesets to process metadata.
... overall syntax is much more uniform now.

<ChrisW> (Ruleset A->B (Ruleset B->C))

ChrisW explains his reading of that.

scribe: ok, misread.

<ChrisW> http://www.w3.org/2005/rules/wiki/BLD#Direct_Specification_of_RIF-BLD_Syntax

<GaryHallmark> what does the ruleset nesting imply about scope of local symbols?

<MichaelKifer> http://www.w3.org/2005/rules/wiki/BLD#EBNF_for_RIF-BLD_Rule_Language

ChrisW: in order to put metadata in a rule you need to wrap it in a ruleset in this syntax.
... the base case for metadata is single rules.

<sandro> No, DONT AVOID THAT. Allow MetaData on Everything.

Harold: looking downwards in our grammar, we could have metadata anywhere, but we wanted to avoid that.

ChrisW: but we can now only use it at rulesets.

Harold: but now with nested rulesets we can again have it anywhere.

<Hassan> +1 on Sandro (metadata should be allowed on everything)

Sandro: every single thing in the syntax has URIs, shouldn't we also allwow for metadata anywhere?

<PaulVincent> +1 on moving RIF metadata to RIF version 2

<sandro> PaulVincent, did you hear someone say that? ("+1" is usually for agreeing with something you just heard.)

<sandro> (not that I disagree)

<Hassan> I also wonder what the real issue is here?...

<PaulVincent> Sorry: it was a variation on the discussion: should be: Proposal: ...

ChrisW: Why do I need to call anything ruleset where I want to add metadata.

Harold: that was similar in jos' proposal.

Jos: no.

<Harold> Just a different 'wrapper name'.

Jos: you need to assign an identifier to a rule, if you want to talk about it - as a rule.

<Harold> "One man's metadata is another man's data"

(jos can you type in the differences agian?)

<sandro> Jos: I used different syntax for metadata to help clarify that the data is not part of the ruleset.

<Harold> "meta" is a relation between two levels.

<Harold> We have already the Frame notion, and know to map it to RDF.

sandro: while jos proposal is maybe logically more complicated, it is more usable.

<Harold> So, it would be ironic to not use our RDF-like Frames for metadata.

ChrisW: I don't see the big difference between the two metadata proposals.

<sandro> chris: use of frame syntax is an aesthetic or communication choice there.

<AdrianP> not necessarily, the new proposal is much more general and supports a set of rules or a singel rule attached with metadata and allows to process meta data with rules

jos: another important difference: in michael's proposal the ruleset identifier is hidden inside the frame.

<sandro> Chris: how do you assign a URI to a ruleset?

<MichaelKifer> iri[]

MichaelK: the main idea is that the metadata is RIF itself, to make metadata processeable.

<sandro> Um, NO, we don't need to process the metadata using rules. That's NOT a requirement.

MichaelK: we can use frames, constants, that's not the point.

<ChrisW> (Ruleset iri[value -> http://rule1] (A :- B))

MichaelK: our approach is more uniform and more powerful.

<IgorMozetic> I think it's a good idea to process the metadata by rules.

<MichaelKifer> iri[](A:-B)

<sandro> I agree, IgorMozetic, but it's *not* a requirement, and may be less important than other issues.

<AdrianP> +1 to Michael and Igor.

Sandro: Let's see the XML of this.
... before making a decision on this.

<AdrianP> e.g. for building a constructive view / scope on a set of rules, e.g. all rules from a particular author

<MichaelKifer> "http://rule1"^^iri(A :- B)

josb: michael or harold should send a mail explaining the proposal to the list.

harold: there is already an example.

<Harold> <Ruleset>

<Harold> <meta>

<Harold> <Frame>

<Harold> <object>

<Harold> <Const type="rif:iri">w3:homepage</Const>

<Harold> </object>

<MichaelKifer> "http://rule1"^^iri[](A :- B)

<Harold> <slot>

<Harold> <Prop>

<Harold> <key><Const type="rif:iri">dc:publisher</Const></key>

<Harold> <val><Const type="rif:iri">w3:W3C</Const></val>

<Harold> </Prop>

<Harold> </slot>

<Harold> <slot>

<Harold> <Prop>

<Harold> <key><Const type="rif:iri">dc:date</Const></key>

<Harold> <val><Const type="xsd:date">2008-04-04</Const></val>

harold: example 5 of BLD

<Harold> </Prop>

<Harold> </slot>

<Harold> </Frame>

<Harold> </meta>

<Harold> <rule>

<Harold> . . .

<Harold> </rule>

<Harold> </Ruleset>

harold: in section 5.2.

<josb> Wasn't it possible to make this more complex?

ChrisW: is there a presentation syntax version of this example.

Harold: we should bring it back, yes.

<sandro> josb :-)

ChrisW: we are over time.

<josb> +1

ChrisW: adjourn

<AdrianP> bye

This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/thsat/right that/
Succeeded: s/this/roundtripping/
Succeeded: s/thsat/that/
Succeeded: s/michaels/michael's/
Found Scribe: AxelPolleres
Inferring ScribeNick: AxelPolleres
Found ScribeNick: AxelPolleres
Default Present: JamesOwen, AxelPolleres, +49.351.463.4.aaaa, AdrianP, Dave_Reynolds, Harold, ChrisW, +39.047.101.aabb, josb, StellaMitchell, Sandro, Mark_Proctor, IgorMozetic, PaulVincent, johnhall, Hassan_Ait-Kaci, Gary_Hallmark, MichaelKifer, LeoraMorgenstern
Present: JamesOwen AxelPolleres +49.351.463.4.aaaa AdrianP Dave_Reynolds Harold ChrisW +39.047.101.aabb josb StellaMitchell Sandro Mark_Proctor IgorMozetic PaulVincent johnhall Hassan_Ait-Kaci Gary_Hallmark MichaelKifer LeoraMorgenstern
Got date from IRC log name: 01 Apr 2008
Guessing minutes URL: http://www.w3.org/2008/04/01-rif-minutes.html
People with action items: jdebruij jdebruij2 jos sandro