<ChrisW> Scribe: DaveReynolds

<scribe> ScribeNick: DaveReynolds

Minutes from last time to be approved next call.

Liason

<StellaMitchell> yes

Chris: meeting between OWL and RIF wg members last Thursday. Minutes were posted.

<StellaMitchell> yes, Sandro sent to both lists

Chris: discussed four areas requiring some coordination.
... (a) rdf:text reasonably well coordinated

<DaveReynolds> though HP comments on that issue

Chris (b): OWL RL profile, could they use RIF syntax instead of arbitrary syntax?

Chris (c): datatypes, both have lists to be support, not a good reason for them to differ.

Chris: the discussion revealed that OWL have changed the interpretation of some of the data types, e.g. so that "1.0"^^xsd:float is an integer for OWL
... and they have owl:real as a supertype of these modified types.
... one implication is that the value spaces of the numeric types are not disjoint.
... they have discussed this with xml schema representatives

Jos: have followed up with Boris, they are working with xml shema 1.1, not 1.0 as we do.

<AxelPolleres> I was very surprised about that disjointness! :-o

<josb> section 2.2.3:

<josb> For purposes of this specification, the value spaces of primitive datatypes are disjoint

Minutes from the RIF/OWL coordination meeting are posted at: http://lists.w3.org/Archives/Public/public-rif-wg/2008Dec/0080.html

<josb> Other applications making use of these datatypes may choose to consider values such as these comparable.

<josb> http://www.w3.org/TR/xmlschema11-2/#lexical-space

<DaveReynolds> the float/integer mapping is far from trivial given over/underflow of mantissa

Chris: fourth topic (d) RDF/OWL compatibility document, that is well in hand.

Jos: all the proposals for changes to SWC were accepted.

Chris: so remaining issues are OWL RL rules and datatypes
... OWL RL RIF rules could be in OWL profile document, separate document or in SWC

Sandro: the first would require making RIF syntax palatable to OWL readership, which may be a challenge
... also the issue of how to handle the list rules which are done as templates in OWL RL rather than by explicit rules
... try to create a proposal which is acceptable to OWL but may be not be possible

Chris: people agreed that the XML form of rules should be available via link but not inline in document

<AxelPolleres> remark: some similar issues concerning xs:string vs rdf:text raised by Andy Seaborne... /me looking for the mail document

<josb> right, in OWL xsd:string is a subtype of rdf:text, but in RIF this is not the case

<josb> ...and the binaries

Dave: three datatype issues rdf:text, list of types, numeric type differences

<ChrisW> ACTION: chris to open rdf:text issue [recorded in http://www.w3.org/2008/12/16-rif-minutes.html#action01]

<trackbot> Created ACTION-674 - Open rdf:text issue [on Christopher Welty - due 2008-12-23].

Dave: for rdf:text then there are issues with stated change to RDF and implicit change to SPARQL
... can be resolved with small changes to text, Andy Seaborne and Dave Reynolds have a suggestion for this

Jos: there is also the issue the rdf:text also reinterprets xs:string as a subtype of rdf:type, this is also an incompatibility but is already an open issue
... this would again have issues for RDF compatibility

<AxelPolleres> +1 for treatment of string as subtype of text

<ChrisW> ACTION: chris to open issue on string subclassOf rdf:text [recorded in http://www.w3.org/2008/12/16-rif-minutes.html#action02]

<trackbot> Created ACTION-675 - Open issue on string subclassOf rdf:text [on Christopher Welty - due 2008-12-23].

Chris: for the list of datatypes which share/don't share just taking union would probably be fine

<AxelPolleres> Dave: reuse of rdf: namespace is not the problem, just wording that would imply that rdf should support rdf:text... if we exclude that explicitly from rdf we should be fine.

<AxelPolleres> (hope I got that right)

<josb> there are more differences....

Sandro: subtypes of string is also an issue (regexp defined subtypes of strings)
... implementation burden, maybe not a big one, but have to decide whether to include and if not then push back on OWL

<AxelPolleres> ... if we add also respective predicates and functions for other datatypes, it will mean considerable effort for DTB, deciding on which preds/functions we want, etc.

Jos: there are more different types such as the binary types (xsd:hexbinary), also owl:dateTime which need to be decided upon

<AxelPolleres> ... that is just a remark, not an objection.

Chris: we should compile the definitive list of differences, decide what RIF wants to support and go back to OWL

Sandro: there are two lists in OWL, the full list of datatypes and the subset for OWL RL
... could restrict the RIF/OWL agreement to just those for OWL RL

Jos: OWL RL already includes many of the tough ones!

<josb> http://www.w3.org/TR/2008/WD-owl2-profiles-20081202/#Entities_3

Sandro: need to weigh benefits to user against cost of implementation

<AxelPolleres> do OWL know how to implement these?

Sandro: not clear how much user pull there is for all of these

Dave: there is also the issue of what builtins are needed for each of these datatypes to make them useful in RIF

Axel: the other schedule risk is whether this is a moving target

Sandro: OWL is at last call, though the specific list for OWL RL is "at risk"

<AxelPolleres> ... if all is fixed, and only equality is required, then we should be fine!?

Axel: could have minimal inclusion just support equality which is all OWL need but not a rich library of associated builtins

Jos: regarding the numerics, inclined to go OWL route, easier for users and elegant

Sandro: hesitant, depends on user community - programmers v. logic folk

Dave: concerned about implementation cost of the float/integer equivalence when handling under/overflow of mantissa

<josb> Dave, what is your feeling about non-disjointness of hexBinary and base64Binary?

<DaveReynolds> jos: I think that's fine, they are just serializations of binary

Public Comments

Chris: updated to RAK, people should look at this
... one comment missed up to now, question concerns value space for rif:local and implementation advice

<AxelPolleres> ok

<AxelPolleres> rif:local is not a datatype, so it also doesn't have a value space... not sure how I should read that question... will have a look though.

<josb> OK, so for these types we don't have a problem with going the OWL way

F2F12

<scribe> ACTION: sandro to set up poll for f2f12 [recorded in http://www.w3.org/2008/12/16-rif-minutes.html#action03]

<ChrisW> ACTION: sandro to set up registration form for F2F12 [recorded in http://www.w3.org/2008/12/16-rif-minutes.html#action04]

<AxelPolleres> can someone paste the link to the respective mail? (concerning rif:local value space)

Chris: a number of people likely to attend remotely, so we should know how many

Sandro: wonders whether to explore video conferencing option

<josb> http://lists.w3.org/Archives/Public/public-rif-comments/2008Nov/0000.html

Gary: not aware of any video conference support in the facility

<ChrisW> ACTION: Gary to look into videoconf support for F2F12 [recorded in http://www.w3.org/2008/12/16-rif-minutes.html#action06]

<trackbot> Created ACTION-676 - Look into videoconf support for F2F12 [on Gary Hallmark - due 2008-12-23].

<Harold> For H.323 clients, NRC colleagues suggest XMeeting on Mac or Net Meeting or Polycom PVX for the PC.

<Harold> I used Net Meeting successfully.

Holiday schedule

<ChrisW> Poll: if we have a telecon Dec 23, would you attend

<LeoraMorgenstern> +1

Show of hands for telecon on 23rd:

<AdrianP> -1

<josb> +1

<Hassan> +1

-1

<Michael_Kifer> +1

<StellaMitchell> -1

<Gary> -1

<AxelPolleres> +1

<sandro> -1

<Harold> -1

<AxelPolleres> :-)

<AxelPolleres> +1 from my desk

Show of hands for telecon on 30th:

<ChrisW> Poll: if we have a telecon Dec 30, would you attend

<LeoraMorgenstern> -1

<AxelPolleres> -1

<Gary> -1

-1

<Hassan> -1

<Michael_Kifer> -1

<sandro> -?

<josb> 0 (not yet sure)

<Harold> 0

<ChrisW> Telecon next week (Dec 23)

<ChrisW> cancel telcon Dec 30

Publications

Sandro: publications waiting on PRD

Adrian: still discussing a question on semantics and whether to publish now or change it
... Christian making a change (not finished as of 1 hour ago)

Action Review

Adrian: probably finalize at PRD telecon

<josb> yes

Action-669 closed

<trackbot> ACTION-669 Incorporate and address Jos' comments from http://lists.w3.org/Archives/Public/public-rif-wg/2008Nov/0190.html closed

Action-666 will finish tomorrow

Action-604 to pending review

<LeoraMorgenstern> continued

<LeoraMorgenstern> (I'll get to it over the break.)

Action-588 continued

<Hassan> on

ACTION-635: RDB2RDF and RIF [17], [11] (10 mn)

<AxelPolleres> that's done

<AxelPolleres> it is an XG

Axel: at the moment nothing more required

DTB

Chris: DTB four issues - negative guards, more general guards, additional OWL-RL datatypes, string predicates

<AxelPolleres> We don't have odditional datatypes yet mentioned in as an issue in the document.

Jos: regarding negative guards and discussion with Sandro on list ...
... Sandro suggested that in practice will be implemented using some external oracle which can report yes/no/unknown for constant
... could have an isLiteral guard so that then with the isLiteral guard could always decide yes/no for the guards like isInteger

Chris: is this explicit in rules or implied by implementation?

Jos: explicit in rules

Sandro: do the use cases for negative guards need this isLiteral guard?

Jos: this isLiteral is just to prevent reasoners having to do case analysis

Sandro: never have to do case analysis over externals

Jos: so does that imply changing the semantics of the guards to only apply to such concrete values
... that's what we did for positive guards but didn't work for negative guards

<AxelPolleres> neither guards not neg guards have a domain specified!

Jos: the external functions don't know about the abstract objects in the domain and so can't be reasoned about by external functions

<AxelPolleres> guards were intended to be defined for everything.

Sandro: not proposing restricted domain, guards are defined for everything, but result might not always be known

<AxelPolleres> as they are defined now, they cannot return "unknown"

Sandro: suggesting that external predicates should be allowed to return unknown

<AxelPolleres> isDATATYPE means that the argument is *known* to be in the value space.

Sandro: handles the test cases discussed in email so ex:a would match neither isInteger nor isNotInteger given no other information

<Hassan> what about raising an exception?

Chris: does this require another truth value

<AdrianP> but then we would need a three-valued truth logic

Sandro: to the external predicates but not the BLD semantics

<sandro> in the case of BLD, it's more like isKnownToBeInteger, and isKnownToNotBeInteger.

<AxelPolleres> isnotknowntobeinteger is the current semantics

<sandro> sandro: Yes, I think in BLD, the positive and negative guards would return false on non-literals.

Chris: so the negative guards would return false on non-literals

<AxelPolleres> (for isNotInteger being true)

<sandro> ex:a = 3 , isInteger(ex:a)

Sandro: then would expect the answer from isInteger to be true but with his proposal the the builtin wouldn't know this and so would still return unknown which BLD turns into false
... then the reasoner would later call isInteger on 3, substituting for ex:a and then return true

<josb> we need them for embedding of OWL 2 RL, for example

Axel: the intention was that the negative guards should be the exact inverse of the positive guards for the original use case, this solution would not satisfy that

<josb> (but a workaround might be possible)

Axel: [gave example but scribe missed it]

Sandro: not convinced that case is really needed in BLD, is it just about handling bad data?

<josb> I think the use case was about working around errors

<AxelPolleres> would the OWL RL translation be fine with modeling negative guards in NAF?

<sandro> DaveReynolds: OWL-RL needs negative guards, so it can test for all literals being equal/not-equal to each other. But an isLiteral guard might do it.

<sandro> isInteger, and isNonIntegerLiteral.

<josb> I would like to have the rdfs:Literal, in any case

Dave: and OWL-RL needs negative type check for validation but that may only need apply to the explicit literals, would need to check that

<AdrianP> maybe it would be easier to extend the semantics and introduce a typed logic

Jos: current OWL embedding uses negative guards in two places, one to check it is a literal at all, might be able to work around by axiomatize somehow

<AdrianP> with sorts for Integer, String etc.

Jos: adding constraint of returning "no" for non-literals would break things in this case

<Hassan> +1 with Jos

Jos: negative guards are a problem, and this modified semantics is rather unintuitive and perhaps not of use

<sandro> Option-1: get rid of negative guards entirely

<sandro> Option-2: switch to "isNonIntegerLiteral"

<sandro> Option-3: requiring rules to use isLiteral guard before the negative guards

<sandro> Option-4: leave it the way it is --- you have to reason by cases

<AxelPolleres> I have a doubt about the usefulness of Option-2. and I further have the impression that Option-4 could simply be emulated by Option-1 + naf.

<sandro> Option-5: drop specific-type negative guards, but keep isNotLiteral

<josb> would also require reasoning by case

<AxelPolleres> is that observation correct?

<AxelPolleres> isLiteral can be emulated by a single rule with a disjunctive body.

Michael: option-3 is not interesting because it puts the burden on the user

<LeoraMorgenstern> I need to think about it some more.

<josb> Axel: classical negation != naf

Straw poll on these options:

<AxelPolleres> preference: 1 or 4 before all other options.

<Michael_Kifer> Option-1

<josb> 1

<DaveReynolds> probably 2

<Hassan> Option-1

<sandro> 1 or 2

<AxelPolleres> (I cannot give a total order)

<AdrianP> Optin 1

<Harold> 1

<DaveReynolds> maybe (in response to Chris question would anyone object to option-1)

Chris: would anyone argue strongly for having negative guards in?

<AxelPolleres> dave, the OWL RL encoding wouldn't work without any form of negation (be it guards or naf), right?

<AdrianP> I suspect that most implementations would map guards to a fully typed logic anyway

(not as scribe) Axel - right, hence my vote for 2

<sandro> Chris: seems like folks are leaning toward removing negative guards.

<josb> Axel, Dave, one can axiomatize negative guards

<AxelPolleres> what about option-1 and moving the OWL RL encoding to a naf dialect?

<josb> axiomatization will be there in < 2 weeks

<sandro> DaveReynolds: I don't see how to do OWL-RL without negative guards, so let's see if someone can figure out a way to do it.

back to publication and PRD draft

csma: not happy with the semantics on conditions and would like it to be reviewed by someone else before publication
... all other changes done, may not be fit for proving PRD is an extension of Core but at least that section should be easier to understand

Chris: could we publish as is and if necessary revise for next WD?

csma: not a show stopper, can publish yes, but want to make it easier to understand
... believe made all the edits, may be some links that need fixing after translation to TR

<AdrianP> we could add some references to standard definitions such Herbrand Interpret. etc.

Chris: unleashes Sandro to do the publication!
... reminder there will be a telecon next week but 30th is cancelled