See also: IRC log
<ChrisW> Scribe: DaveReynolds
<scribe> ScribeNick: DaveReynolds
Minutes from last time to be approved next call.
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.
<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
... 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
... 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
... 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!
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
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> 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
<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
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.
<ChrisW> Poll: if we have a telecon Dec 23, would you attend
Show of hands for telecon on 23rd:
<AxelPolleres> +1 from my desk
Show of hands for telecon on 30th:
<ChrisW> Poll: if we have a telecon Dec 30, would you attend
<josb> 0 (not yet sure)
<ChrisW> Telecon next week (Dec 23)
<ChrisW> cancel telcon Dec 30
Sandro: publications waiting on PRD
Adrian: still discussing a
question on semantics and whether to publish now or change
... Christian making a change (not finished as of 1 hour ago)
Adrian: probably finalize at PRD telecon
<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> (I'll get to it over the break.)
<AxelPolleres> that's done
<AxelPolleres> it is an XG
Axel: at the moment nothing more required
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
... 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.
<DaveReynolds> probably 2
<sandro> 1 or 2
<AxelPolleres> (I cannot give a total order)
<AdrianP> Optin 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.
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
... reminder there will be a telecon next week but 30th is cancelled