See also: IRC log
<ChrisW> Scribe: LeoraMorgenstern
<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
Chris: Everything is fine with the OWL working group
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 presentation 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
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 ground lists would affect the syntax of Core.
<AdrianP> we should keep ground 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
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 list terms there can be no variables
<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 constructing 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 lists, 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 lists
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 externals.
<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, the 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 tailed lists should be out of Core?
<csma> I did not hear
<Harold> Open lists (tailed lists) are not needed for any Core builtin etc.
<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 are 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
<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 go with extension instead of 1-1
sandro: extension seems to be
easier than 1-1.
... that is, easier to implement
<sandro> dave: extension is lesser of two evils.
<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 the 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 want <List><some_role_tag rif:ordered="yes"> TERM* </some_role_tag ></List>
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 constructed 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 construct.
<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.