RIF telecon 3 March 2009

 

 

<csma> item+ Admin

<csma> agendum+ Admin

<csma> agendum+ Liaisons

<csma> agendum+ F2F13

<csma> agendum+ Actions

<csma> agendum+ safeness

<csma> agendum+ List data type

<csma> agendum+ issue 80

<csma> agendum+ issue 92

<csma> agendum+ PS

<csma> agendum+ AOB

<csma> next item

<csma> http://lists.w3.org/Archives/Public/public-rif-wg/2009Feb/att-0122/20090224-rif-minutes.html

<csma> PROPOSED: to accept the minutes of Febraury 24

minutes of Feb 24 accepted

<csma> RESOLVED; to accept the minutes of Feb 24 telecon

<csma> next item

<csma> next item

<ChrisWelty> action-709: complete

<trackbot> ACTION-709 Put merged PS on agenda for Mar 3 notes added

<ChrisWelty> action-592: completed

<trackbot> ACTION-592 Open issue based on the White Board line: "What about methods -- Ignore" notes added

<csma> next item

<csma> http://www.w3.org/2005/rules/wiki/Core#Safeness

<csma> http://lists.w3.org/Archives/Public/public-rif-wg/2009Feb/0065.html

question is whether to take josb's definition or axel's, which is stricter

<ChrisWelty> axel: would prefer to have finiteness as well as safeness

csma: should safety be about termination or about implementability in dialects like PRD?

axel: worried about systems like DLV (stable models), which do grounding. Therefore, safeness should guarantee that grounding is finite.
... might go for 2 definitions: one general, like we have now, and another very strict one

<josb> daver probably has an opinion about this

<AxelPolleres> the discussion is still about whether we want safeness for core that inplies finite minimal models or not.

<ChrisWelty> jos, do you have an idea what DaveR's opinion is (more or less)?

<josb> he does not want finiteness

<Zakim> sandro, you wanted to say I would call it a different dialect

<ChrisWelty> </chair>i'd be happy to leave safeness where it is, and not make it more strict<chair>

axel: strict condition is the common denominator

<josb> me too, but I don't have a strong opinion either way

sandro: we want just one safeness cond in core so that all engines will be able to interoperate through Core.

<ChrisWelty> Straw Poll: (+1) go with stricter safeness requiring finiteness, (0) don't care, (-1) stick with current safeness

csma: is there a constituency for less strict (termination)?

<AxelPolleres> All I say is: If we do not restrict finiteness in Core, we are on the safe side for ALL systems.

<josb> (-0.1)

<AxelPolleres> not more, not less.

<ChrisWelty> Straw Poll: (+1) go with stricter safeness requiring finiteness, (0) don't care, (-1) stick with current safeness

several: developers of interested systems (eg, DLV) should make an effort to become compliant.

<AxelPolleres> +1

<sandro> +0 I care, but don't know

<AdrianP> 0 (don't know yet)

<ChrisWelty> -1

<Harold> +0.75

<sandro> chris: -1 allows infinit, +1 disallow infinite

<Gary> -0.5

-0.5 (without finiteness)

<csma> 0 Icare but I do not know

<ChrisWelty> possible path forward: add section on finiteness to CORE safety, but label it "AT RISK"

sandro: use the currens (lenient) definition; add axel's restrictions and make them at risk

<AxelPolleres> +1 to add at risk!

<sandro> PROPOSAL: The issue of finiteness will be At Risk through CR, as we get implementor feedback. We need to know who wants and/or doesn't want this limitation in Core.

<sandro> PROPOSAL: The issue of finiteness will be At Risk through CR, as we get implementor feedback. We need to know who wants / doesn't want this limitation in Core. (Safeness as defined by Jos not being in question.)

<csma> next item

<sandro> http://www.w3.org/TR/xpath-functions/#sequence-functions

<Harold> These lists would not be (potentially non-ground) terms but (always ground) built-in data.

csma: the lists in question are not Prolog-like lists, but a datatype, like xsd lists.

<AxelPolleres> I don't lists as fitting with our current definition of "datatype"

<Gary> it would be very useful to retrieve the multivalues of a frame slot as a list

<Harold> OWL used to have lists more general than built-in data; what about OWL 2?

<josb> They are!

<Gary> xml schema doesn't support lists of lists, I think

<Harold> (often such flat lists are called sequences)

<AxelPolleres> Can we use rdf:List?s

<sandro> Yes, I'm very much in favor if (1) we can make it work (2) it wont slow us down too long.

<AxelPolleres> What are the implications for DTB?

<sandro> I'm looking at: http://www.w3.org/TR/xpath-functions/#sequence-functions

<csma> http://www.w3.org/TR/xmlschema11-2/#list-datatypes

why not go back to the earlier effort and introduce list terms (after fixing)?

<sandro> sandro: I think for Core/PRD we need to disallow variables from lists....

<AxelPolleres> I think that terms with s dedicated/reserved list constructor function symbol would be the way to go.

<josb> I would imagine the only problem is if there are non-ground lists in the head

<sandro> (unbound variables, of course)

<Gary> I think the list methods are builtins (externals) and should inherit the same safeness as the other externals

<Harold> For lists as terms we had http://www.w3.org/2005/rules/wg/wiki/Core/List_Constructor and http://www.w3.org/2005/rules/wg/wiki/Core/List_Constructor-alt

<Gary> does anyone see how to bind a list to *all* the values of a multivalued frame slot?

<Harold> Gary, I think this would be a kind of aggregate.

<sandro> proposed: ACTION: Michael draft a proposal for lists that will work in Core (and other dialects)

<Harold> (In Prolog bagof, listof have been used to collect all elements from a query, which could retrieve all the values of a multivalued frame slot.)

<sandro> proposed: ACTION: kifer draft a proposal for lists that will (hopefull) work in Core (and other dialects)

<sandro> ACTION: kifer draft a proposal for lists that will (hopefully) work in Core (and other dialects) [recorded in http://www.w3.org/2009/03/03-rif-minutes.html#action01]

<trackbot> Created ACTION-711 - Draft a proposal for lists that will (hopefully) work in Core (and other dialects) [on Michael Kifer - due 2009-03-10].

<josb> How about: no non-ground lists in the head

<sandro> works for me, Jos.

<csma> next item

<sandro> issue-80?

<trackbot> ISSUE-80 -- Shoudl we extend DTB to include more general builtins -- OPEN

<trackbot> http://www.w3.org/2005/rules/wg/track/issues/80

<AxelPolleres> I agree to have literal-no-equal should be symmetric.

csma: what is special about pred:LiteralEqual? Why don't we have the same problems with pred:LiteralNotEqual

jos: pred:LiteralEqual and pred:LiteralNotEqual should be complimentary. We just haven't defined them

<AxelPolleres> need to go, sorry, bye all! will read the notes on the outcomes of this and follow up per mail if I have additional opinions.

<josb> http://lists.w3.org/Archives/Public/public-rif-wg/2009Mar/0022.html

josb: XSD distinguishes betw identity and equality (eg, DateTime items can be equal because of different time zones, but they would not be identical)

<csma> http://lists.w3.org/Archives/Public/public-rif-wg/2009Feb/0128.html

<ChrisWelty> 1) Drop pred:literal-equal

<ChrisWelty> 2) Leave pred:literal-equal as is (redundant with RIF =)

<ChrisWelty> 3) Redefine pred:literal-equal to perform all the datatype specific equality tests including numeric, and remove those datatype specific tests from DTB.

<josb> I strongly prefer option 1)

<josb> I would object to 2) unless someone can make a very strong case

<AdrianP> option 1

<Gary> 1 or 3 but not 2

<Gary> 1^^int = 1^^float is inconsistent, right? value spaces are disjoint

<josb> datetime-equal

+1 option1

<csma> which option do you support most? 1, 2 or 3

<sandro> right Gary

<Harold> 1

<josb> 1

<AdrianP> 1

<ChrisWelty> .9

<sandro> 1 i guess maybe maybe

<Gary> mild pref for 3

<ChrisWelty> object to option 1?

<ChrisWelty> none

<ChrisWelty> object to option 3?

option 3 is complicated

<ChrisWelty> none

<josb> and also drop literal-not-equal

<csma> PROPOSED: drop pred:literal-equal

<ChrisWelty> my understanding was that we would KEEP not-equal

<ChrisWelty> that wasn't part of the options 1-3

<josb> I don't understand why we would keep not-equal, but drop equal. Seems very awkward.

<Gary> I agree with Jos. Keep both equal and not-equal, or neither

<AdrianP> bye