RIF Telecon Cinco di mayo 2009 -- 05 May 2009

<ChrisW> Scribe: LeoraMorgenstern

Admin

<ChrisW> http://lists.w3.org/Archives/Public/public-rif-wg/2009Apr/att-0165/28-rif-minutes.html

<ChrisW> PROPOSED: Accept APril 28 minutes

<csma> +1

<ChrisW> RESOLVED: Accept APril 28 minutes

Jos: Would like to speak briefly on built-ins in DTB that rely on XPATH definitions.
... numerics, and possibly others

Liason

Chris: Everything is fine with the OWL working group

Action Review

Action 802 on Harold: Done

<trackbot> Sorry, couldn't find user - 802

<ChrisW> action-802: closed

<trackbot> ACTION-802 Update the xml syntax for generalized quanitifiers by may 7 notes added

<trackbot> If you meant to close ACTION-802, please use 'close ACTION-802'

<ChrisW> close action-802

<trackbot> ACTION-802 Update the xml syntax for generalized quanitifiers by may 7 closed

<csma> done

close ACTION-801

<trackbot> ACTION-801 Update PRD presentatoin syntax closed

close ACTION-800

<trackbot> ACTION-800 Add PRD conformance clause closed

close ACTION-799

<trackbot> ACTION-799 Extend SWC with lists, with 1-to-1 and extensions as alternatives closed

close ACTION-798

<trackbot> ACTION-798 Write conformance section for SWC closed

close ACTION-797

<trackbot> ACTION-797 Update xml syntax of lists closed

close ACTION-793

<trackbot> ACTION-793 Write a core version of factorial closed

continue ACTION-792

<csma> both continued

Harold still working on monolithic version before Gary's action 780

<csma> 763 is done

765 continued

close ACTION-763

<trackbot> ACTION-763 Add lists to PRD. closed

762 continued

close ACTION-761

<trackbot> ACTION-761 Add the restriction on list in Core closed

close ACTION-758

<trackbot> ACTION-758 Update CORE to implement issue-99 and issue 100 closed

<csma> gary, I did 744, too

close ACTION-755

<trackbot> ACTION-755 Update xml schema syntax for import closed

close ACTION-749

<trackbot> ACTION-749 Draft E-S safety and make informative instead of at-risk, update conformance requirment closed

close ACTION-745

<trackbot> ACTION-745 Draft some text for BLD about consumers doing translations-to-Core when they can. closed

Harold: that is last sentence of intro

<csma> 744 is done

<Harold> (of BLD)

close ACTION-744

<trackbot> ACTION-744 Add text to PRD about how folks should get rid of do/assert when they can. closed

740 continued

close ACTION-738

<trackbot> ACTION-738 Add all boolean builtins closed

733 continued

708 continued

708 is moved to Stella (adding category to test cases: import rejection)

<scribe> done

close ACTION-588

<trackbot> ACTION-588 Remove examples in 4.4 that we have no dialect for, and add comment to make that clear closed

564 continued

Review LastCallPlan

Chris: First step in Last Call Plan was to finish up all documents today.
... Then internal reviewers could review it, and we could vote next week.

Harold: Dave recently did final edit; I only need to update XSD; reviewers can basically review it anyway.

Adrian: But Jos is revising safeness condition, and there is still some editing going on.

Jos: It's done, now.
... rewrote normal safeness condition; strong safeness is now informative.

Dave: email discussion on grand lists (check) would affect the syntax of Core.

<AdrianP> we should keep grand lists in Core

sandro: does not like the term ground lists; has several possible alternative terms
... super-safe constructor list --- nobody sees reason for it.

<AdrianP> I don't know the term "supersafe" - never heared of it

chris: can people review Core exclusive of list section?

<AdrianP> I think "ground" is well defined in many logic programming text books

changkai: ok, will review Core with the understanding that section on lists, and Harolds' changes to xml schema, may change

<sandro> AdrianP, the reason supersafe doesn't exist in literature is because it's not a useful thing to do. None-the-less, it's what you've spec'd in core.

chris: BLD document is not affected by the lists issue

Harold: yes, BLD is ready for review

<csma> yes

chris: How does SWC stand?

jos: I did everything, except for two alternative semantics for connecting lists, plus did not completely go through proofs in appendix, But these are not crucial
... I did go through the OWL-2 specs

chris: what about DTB? Only thing left is the numeric paths, to be discussed today.
... PRD. How does that stand?

csma: PRD is ready to be reviewed. I still plan to move sections on built-ins and conformance in front of XML, and do some other minor editorial changes.
... for DTB, there is also discussion about built-ins
... that still needs to be done

Chris: FLD

<sandro> yeah, XSD went to CR.

Harold: I think it's ready for review; must check about new XSD spec, but this should not affect review.

<sandro> (which bodes well for us depending on them)

<StellaMitchell> yes

Lists

Chris: Several things regarding lists:

<sandro> http://lists.w3.org/Archives/Public/public-rif-wg/2009May/0056.html

<sandro> PREMISE: forall ?i (

<sandro> if ex:p(?i) then ex:q(List(ex:foo ?i))

<sandro> )

<sandro> ex:p(1)

<sandro> CONCLUSION: ex:q(List(eg:foo 1))

Sandro: I sent a test case illustrating the issues:

(cut and pasted above)

Sandro: should rule above be in Core?
... as I understand the current Core specs, that would be a syntax error, and I don't think it should be.
... It's a syntax error because lists don't take variables. But this behavior is goofy.
... perhaps there should be a built-in for lists.

josb: two different understandings of resolution at F2F.

<josb> List(ex:foo ?i)

jos: Sandro's understanding: safe lists in Core; others' understanding was that inside lit terms there can be no variables

s/list terms/lit terms/

<AdrianP> yes, I added a restriction for ground lists, which are variable free

Harold: it's not a restriction; it's just that if there are no variables in the list, it's automatically safe.

Sandro: no, this winds up not being allowed.

Chris: what happens if we go to the Core spec that Sandro wants?

Harold: we need both built-in and function symbol for construcdting lists

<AdrianP> we probably need a kind of external list built-in anyway, e.g. to map Java lists to RIF lists (at least from a practical point of view in PRD)

<josb> actually non-ground lists are in Core: http://www.w3.org/2005/rules/wiki/Core#Terms_of_RIF-Core

<DaveReynolds> Jos - yes I was just looking at that

<Harold> myemployees( List(John Mary Fred) )

jos: to correct what I said earlier: I said variables not allowed in liss, but that's not in the formal spec of the language. BNF doesn't agree with the informative spec.

sandro: let's take the list constructor out of Core. Makes everything a lot simpler.
... you would do it all externally

jos: how can you work with liss if they are not in the language?
... sounds very awkward

chris: can you explain again the objection?

jos: need to support constructed terms, need to support unification.
... this way you just consider lists as atomic and just pass them to externals which do the processing for you.

<Harold> As it stands now, we can bind variables to ground lists in Core.

chris: lists got into Core, inherited downward from PRD. Would this affect PRD?

<csma> yes

gary: I don't see the difference between Core and PRD wrt the arguments Sandro is making.

<csma> PRD is not restricted to "ground" lists, as far as I know

chris: so, Gary, you would want a built-in, too?

<sandro> Gary: The semantics of the builtin are fine, but the syntactic sugar of the List keyword is nice, yeah.

gary: I'd be okay with getting rid of the LIST keyword and having everything in exernals.

<josb> To me it seems awkward to have lists, but not be able to get them out, e.g., through querying

hassan: We have a need for collections, for aggregates, in PRD. Lists are one way of doing it.

<csma> zakim unmute me

<Harold> In Core, with the stored fact ouremployees( List( List(Peter Mark Lisa) List(John Mary Fred) ) ), we can query ouremployees( List( ?X ?Y )) getting bindings ?X = List(Peter Mark Lisa) and ?Y = List(John Mary Fred).

<cke> Lists are useful to provide a list of values: color in (red, blue, green, etc.)

chris: are we losing something we want, if we get rid of lists?

harold: yes. See above example.

<csma> hassan, te idea was to have indexable lists

Chris: remember, we didn't have lists a month ago. PRD wanted them, we added them to BLD.

<sandro> Harold: use func:mklist

Harold: wants a built-in for lists.

<Harold> New builtin mklist returns List terms.

<sandro> candidate names: List and mklist .... drop List from syntax, but keep in Alphabet.

<Harold> mklist( (2+3 mklist(a b) ) returns List( 5 List(a b)).

<AdrianP> such a built-in constructor makes sense, since it can be used to creat RIF lists from "external" data values

<josb> no

<josb> not a built-in

harold: no open lists, just n-ary lists

<sandro> mklist only has to think about closed lists, so no problem here.

sandro: "list" can stay on the syntax: maybe we should have a more arcane term so users will be steered away from it (since its functionality is so limited)

<ChrisW> '(a b c)

<ChrisW> (list 'a 'b 'c)

<sandro> sandro: yes, it is like that.

<csma> deciding whether to use the term or the built-in: isn't that something for the implementation?

<AdrianP> safeness for external built-ins would automatically apply to mklist built-in

<ChrisW> ACTION: adrian to update mathematic syntax for Core to reflect restricted lists [recorded in http://www.w3.org/2009/05/05-rif-minutes.html#action01]

<trackbot> Created ACTION-803 - Update mathematic syntax for Core to reflect restricted lists [on Adrian Paschke - due 2009-05-12].

<MichaelKifer> but it is not a constant

dave: call it something like "list constant"

<csma> and we would use only one PS for both?

<Harold> List(a b c) is analogous to Quote( mklist(a b c) ) except we have no Quote.

<ChrisW> ACTION: sandro to add make-list to DTB [recorded in http://www.w3.org/2009/05/05-rif-minutes.html#action02]

<trackbot> Created ACTION-804 - Add make-list to DTB [on Sandro Hawke - due 2009-05-12].

chris: sandro will add mklist (or actually make-list)

<sandro> sandro: csma, yeah, this naming issue only matters for people write in the presentation syntax.

jos: have to update safeness criteria with respect to this discussion.

<AdrianP> ground lists are safe, they don't need bindings since they have no variables

<csma> zakiim, mute me

csma: I heard failed lists should be out of Core?

<csma> I did not hear

<Harold> Open lists (failed lists) are not needed for any Core builtin etc.

<didn't hear response, and not sure htat I heard the question>

<csma> so you want them out of Core?

<Harold> Open lists are only useful when there is a variable in the tail (after the "|"), but there are no variables in Core lists.

<josb> yes

<csma> It has never been decided, nor discussed, that they were not in core

<csma> that's why i wanted to ascertain

chris: open lists ae not in Core; they are in PRD; the PRD folks can take them out if they want.

<ChrisW> csma - yes they appear to NOT be in Core

<cke> Open lists are not in PRD

sandro: <get this from Sandro>

<csma> ok, i will remove them from prd, then

<josb> in this case, deep-equal becomes redundant

<sandro> yes, jos

<ChrisW> ACTION: sandro make list membership builtins use rif:= [recorded in http://www.w3.org/2009/05/05-rif-minutes.html#action03]

<trackbot> Created ACTION-805 - Make list membership builtins use rif:= [on Sandro Hawke - due 2009-05-12].

<josb> do we remove deep-equal?

<ChrisW> ACTION: sandro remove deep-eq [recorded in http://www.w3.org/2009/05/05-rif-minutes.html#action04]

<trackbot> Created ACTION-806 - Remove deep-eq [on Sandro Hawke - due 2009-05-12].

<sandro> D-sub-list as the image of I-list

<Harold> I_list(Dind) is disjoint from the value spaces of all data types in DTS.

<Harold> (http://www.w3.org/2005/rules/wiki/BLD#Semantic_Structures)

<Harold> ((Search for 'injective' in the BLD page.))

michael: will be defining and adding D-list

<ChrisW> ACTION: jos to update safeness for lists [recorded in http://www.w3.org/2009/05/05-rif-minutes.html#action05]

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

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

jos will update safeness for lists

<sandro> ACTION: kifer to add D-sub-list to BLD, with an anchor so List builtins can refer to it. [recorded in http://www.w3.org/2009/05/05-rif-minutes.html#action06]

<trackbot> Created ACTION-807 - Add D-sub-list to BLD, with an anchor so List builtins can refer to it. [on Michael Kifer - due 2009-05-12].

<csma> xml syntax for lists

jos: still have rdf-rif combination lists

sandro I have been convinced to with extension instead of 1-1

s/to go with/to with/

sandro: extension seems to be easier than 1-1.
... that is, easier to implement

<sandro> dave: extension of lesser of two evils.

s/is lesser/of lesser/

<sandro> dave: in either case I'm going to differ from the standard to some degree. easier to add something to standard, vs fall short of standard.

josb: can always tweak conformance, so people don't have to comply with this.
... would not be able to have RDF FIRST and LAST in rule bodies. Would wind up being hte same as querying.

<sandro> sandro: yeah, don't allow rdf vocabulary in RIF.... that should work.

<sandro> sandro: if you're querying an RDF graph that has RIF lists in it, you have to convert them to RDF lists.

sandro: it's okay to require supporting this. If you query an RDF graph with RIF list, shoud be able to get RDF list.

<josb> PROPOSED: RDF-RIF lists semantics will be 1-to-1, but in conformance we only require supporting combinations in which rdf:first, rdf:rest, and rdf:nil are not used in the rules

<sandro> jos: So you only have to think about rdf list vocabulary in going to RIF and from RIF to RDF, but NOT during RIF rule operation.

<josb> sorry, my proposal actually doesn't work, because you can still access the RDF list construction using variables

sandro: so can we fall back to using conformance to say ...

<sandro> jos: extension, with 1-1 being at-risk.

jos: no good way to handle this using conformance: can always manipulate the RDF lists to query ..

chris: which brings us back to where we were last week.

sandro: so, we're at extension semantics with 1-1 being at risk.
... idea is: 1-1 would be nice, but we don't yet know how to implement it. Maybe one day, we will.

<sandro> PROPOSED: RDF-RIF list semantics will be at least "extension", with 1-to-1 being 'at risk'.

<sandro> +1

<josb> http://www.w3.org/2005/rules/wiki/SWC#Common_RIF-RDF_Interpretations

<ChrisW> +1

<josb> +1

<DaveReynolds> +1

<MichaelKifer> +1

<AdrianP> +1

<ChrisW> ACTION: jos to make "1:1" for rdf:lists be at-risk [recorded in http://www.w3.org/2009/05/05-rif-minutes.html#action07]

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

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

<sandro> RESOLVED: RDF-RIF list semantics will be at least "extension", with 1-to-1 being 'at risk'.

<csma> xml syntax for lists in Core is <List> TERM* </List>; should be <List><some_role_tag rif:ordered="yes"> TERM* </some_role_tag ></List>

<josb> ok

<ChrisW> propose: extend meeting by 10 mins

<csma> +1

<sandro> chris: extending meeting by 10 mins.

<ChrisW> resolved: extend meeting by 10 mins

<Zakim> csma, you wanted to ask about the xml syntax of lists

sandro: case that you state, Christian, but also case of open lists.

csma: I wrote of closed lists.

sandro: okay with not having ordered tag

<cke> I prefer directly: <List> TERM* </List>

sandro: will have to do special processing for lists, anyway.
... for open lists, that's different.

<csma> Open lists have <List> TERM* <rest> ... </rest></List>

<AdrianP> yes, with open lists we would have roles like first and rest,

<cke> order can be an attribute of <List>

csma: why are lists different?

sandro: because they have multiple values

<csma> they are not the only ones

<csma> another example is the argument list in expr

<csma> or atoms

<josb> lists are terms

<csma> beurk

<csma> but i do not really care

<csma> like: puke!

<josb> To me they smell like construcdted terms :)

<AdrianP> yes, agree with Sandro - lists are like datatypes

<ChrisW> oh, "yuck"

<sandro> <OpenList><part1><List>.....

<csma> yep

harold: open lists reflect vertical bar of prolog syntax: good for pattern matching.

<csma> csma and many french people use it

<ChrisW> add me to that closed list

<csma> yes

csma can live with the aesthetically displeasing aspects of this construcdt.

<Harold> http://www.w3.org/2005/rules/wiki/OWLRL

<josb> I understood we were not going to merge it with SWC

<sandro> sandro: FPWD, for WG note....

<ChrisW> PROPOSED: make OWLRL document a WG note

<csma> ok, so no rif:ordered="yes" in <List>?

<cke> we need the rif:ordered attribute, but it's optional and default to false

<ChrisW> RESOLVED: make OWLRL document a WG note

<csma> yes

meeting adjourned.

- DRAFT -

RIF Telecon Cinco di mayo 2009

05 May 2009

Attendees

Contents

Admin

Liason

Action Review

Review LastCallPlan

Lists

Summary of Action Items

Scribe.perl diagnostic output