See also: IRC log
<bijan> You mean I have to listen to myself talk?
<csma> Paula, didn't you post regrets? I changed the agenda because of that!
Hi ... is anyone on the phone?
<bijan> I am
<bijan> But last I checked I was all alone
<PaulaP> I'm online for the first part of the telecon...but on the call
<PaulaP> but NOT on the call...sorry
<PaulaP> I didn't know that the wireless connection will be ok here, we are on a small island for our annual project meeting
<scribe> ACTION: review to [recorded in http://www.w3.org/2007/11/27-rif-minutes.html#action01]
<csma> action-383 done
PROPOSED: Accept minutes of telecon of 11-20-07
RESOLUTION: Accept minutes of telecon of 11-20-07
PROPOSED: Accept minutes of F2F8
Actually, that should be in 3 parts (first day, second day, breakout sessions)
RESOLUTION: Accept minutes of F2F8
<ChrisW> I can't access the WG web pages - "Forbidden due to abuse"
Christian: Discussing responses to public comments
csma: There was one question about negation and disjunction on public comment list
csma: Axel proposed a reply; if there's no objection, I propose we send Axel's reply.
csma: Can Axel send the reply?
Sandro: yes, as long as others have read it and are comfortable with it.
csma: I have read it, and I'm comfortable
<PaulaP> +1 for Axel's reply
csma: Also, Peter Patel-Schneider had some comments regarding BLD on the public list
... Three actions on Michael relative to this comment
josb: Michael not here; we need to defer the discussion
No news on liaisons
csma: Very few people have responded to Sandro's questionnaire.
... Action 380, on me, has been done
... Actions on Igor and Axel with regard to posting date preferences for F2F9
... Action 379 on Igor has been done too.
... Problem with dates: can only be in the last 2 weeks in February; moreover, Harold can only make the last week in February.
csma: Michael can't make the 26th; Chris can't make the 28th; Dave and Harold can't make the previous week.
... Perhaps we need to move F2F9 to March or January?
chris: Seems so.
Sandro: Too late for January. We can try for March; it may turn out to be worse.
csma: And March is very late relative to the end of the WG
harold: I could do February 20-22
igor: I can't make it those days.
dave: I can't make it those days either.
... But I could attend by phone.
csma: There seems to be a consensus to have F2F9 on February 21-22, either in Galway or Paris.
<josb> +1 for Paris :)
<PaulaP> +1 for Paris (sorry Axel :) )
csma: Let's have the meeting in Paris.
Back to liaison:
sandro: There's supposed to be a formal announcement from W3C on the extension of the Working Group.
... Which would one hope, bodes well, but we don't know, and we have to wait.
Back to OWL compatibility:
csma: Checking for actions ... no actions
josb: I've drafted several issues. There are several decisions that have to be made to enforce compatibility with OWL.
... Similar issues as arose with ensuring compatibility with RDF.
... First issue : the different versions of OWL.
... If we specify compatibility with OWL-DL, we automatically have compatibility with OWL-Lite, but not with OWL-Full, which has a different semantics.
... So we have to specify which version we're compatible with.
... If we just decide to go with OWL-DL, we can just ignore all the issues that arise from OWL-Full
... Syntax of OWL-Full and RDF are exactly the same.
... In case of OWL-DL, syntax is not the same. Abstract syntax specification is quite different from RDF.
... But there is an RDF representation of abstracft syntax of OWL-DL.
<bijan> I wonder how the fact of a new version of owl affects this deliverable
josb: <Discussion of different options in blue highlighted box in link just posted.>
<bijan> I'll note that OWL DL is a fairly significant fragment of OWL Full, so workign with OWL DL gets *some* Full joy
josb: that's as far as syntactic compatibility.
... Semantic compability is a thornier issue.
<bijan> Both semantics are normative
<Harold> Maybe the OWL Full species is not a main issue for RIF compatibility with a new version of OWL (based on OWL 1.1): http://www.webont.org/owl/1.1/tractable.html#8
josb: Various issues have to be faced, whether we go for compatibility with OWL-Full or Owl-DL.
... Decision has to be made to go for straightforward correspondence of models
... or as results obtained from questioning an external oracle.
csma: If we go with the second option (external oracle), do we get a pass on the syntactic compatibility issues?
josb: No -- still must deal with them
chris: several people on the irc have brought up the point that there will be a new version of OWL.
... Perhaps we should have some liaison with the OWL group to come up with compatibility with new standard.
<Zakim> bijan, you wanted to talk about owl 1.1
chris: better than just picking one of the old versions and ensuring compatibility with that old version.
bijan: Current status quo of OWL-DL 1.1 very advanced, but this is not true of OWL-Full.
... There's a possibility that eventually there will just be one OWL --- some of OWL-Full will be dropped.
... In terms of implementations: there are several implementations of OWL-DL, but implementations of OWL-Full seem to rely on a patchwork of various things, SWRL, RDF, etc.
<bijan> I wouldn't mind transfering the owl compatibility to the OWLWG
josb: Regarding OWL 1.1 --- Scenario Chris sketched of collaboration between OWL and RIF won't work, because if we're lucky enough to get an extension, it will only be for 6 months.
... We shouldn't build anything into the language that make compatibility with further extensions impossible.
... But that may be as far as we should go.
<bijan> +1 to a lightest possible compatibility document!
<bijan> There is also an OWLED TF on rule integration
josb: That is, we should aim for the lightest possible compatibility document.
... We can make it very light by saying we extend RDF compatibility to OWL-DL and OWL-Full.
... But that's not the lightest possible for the reader, who is more used to reading about a direct model-theoretic compatibility.
(Reminds me of what Shaw said: If it's easy to write, it's usually hard to read, and vice versa. "Hard writing makes easy reading. Easy writing makes hard reading." )
bijan: I would imagine that such a document wouldn't be picked up a whole lot by the OWL reasoner community. So, realize it would probably be ignored by the OWL implementors' community.
... If I just saw an extension of the RDF semantics, I would probably just ignore it.
csma: And after all, we're doing this document for the OWL community.
bijan: But I'm speaking for myself, not for the OWL community.
... What I'm looking for from the RIF is an interoperable syntax.
... But if it came with a lot of baggage, I might ignore it.
<csma> ackm josb
sandro: Primary purpose of deliverable: There are users who want to use OWL and want to use rules, and they want to know how to use both together. E.g., Christine Golbreich. We need an answer for such people.
<Harold> Perhaps we should interpret 'lightest' in the sense of the OWL species -- starting with OWL Lite and moving up to OWL DL (as used in SWRL), but postponing OWL Full to Phase 2?
sandro: May mean paying more attention to SWRL than we have recently.
<bijan> There are several editors that generate SWRL syntax
csma: Like making sure that SWRL is covered by BLD,
sandro: I think SWRL can be covered by a small extension to Core.
<DaveReynolds> OWL Full more relevant to us than OWL DL in that our OWL work tends to be of the RDFS++ style that Bijan outlined
<bijan> All reasoning implemetnations I know of interpret it as DL safe...with a few translation approaches in the offing (i.e., a prototype translation to FOL, and some translation to OWL 1.1 TBox axioms)
josb: I agree with both Bijan and Sandro. Our goal shouldn't be to make the lightest possible document, but to make this easy for people ---those who want to use OWL and rules --- to use.
<bijan> (All, nigh compelte OWL DL + SWRL rules implementations, i.e., Racer, KAON2, and Pellet.)
josb: maybe have 2 documents, one for OWL-DL, and one for OWL-full
csma: And for OWL-Full, just extend RDF compatibility?
sandro: If BLD doesn't depend on OWL compatibility, then we have more time to work on OWL compatibility, and therefore we may have the time to hook up with the OWL community.
<bijan> I'm biased to something that supports existing and likely near-term implementations. It helps scope the problem; it provides immediate support to users; it's more or less testable
sandro: If it's the case that we have to ensure these different types of compatibility
... <Sandro dropped off call; see below for his remarks>
<bijan> For example, I'm interested in supporting hex predicates in Pellet, but that's several years off.
csma: Should we talk to the OWL WG?
<bijan> The OWLWG will *know* in the next 6-9 months :)
sandro: Maybe we can ask the OWL WG to ask us whether we should do the two types of compatibility separately or work on some sort of merged version
chris: Yes, can't ignore the fact that OWL is changing.
... We have an opportunity to do a nice job with integration with these two different things.
csma: Especially, since although BLD will be last call in May, there will be more time until it is a recommendation.
bijan: OWL task force just got a surge of interest; possible we might be interested in getting people to work, review, support this effort.
... Peter is coming to Manchester before the owled meeting Boris is coming; can get lots of stuff going.
josb: It seems like we'd have to wait for the recommendation for OWL 1.1
chris: No, I'm talking about jointly making a recommendation for OWL and BLD.
... Having a joint task force could influence the evolvement of these two.
... I specifically don't want to be in the situation where subgroup of OWL tells us what to do, or vice versa.
... who will be on this task force from RIF?
bijan: Lot of start-up overhead at the moment. No significant push possible until after the holidays/first f2f for owl 1.1.
<bijan> My survey: http://spreadsheets.google.com/pub?key=pTmcCXR-dV6TdDo24Tse-fQ
bijan: had 94 people at last owled, but based on polling, many fewer people willing to actually work on this, because what they have works well enough.
hassan: I agree with what most of what's been said, but there's a bit of a chicken-and-egg argument here. OWL 1.1 isn't going to be that different from current OWL, so we can start looking at likely intersection between current OWL and OWL 1.1
csma: how does it work? Does a member of such a task force have to be a member of both WGs?
<bijan> I've seen task forces with members disjointly from each wg
<DaveReynolds> I'd like visibility at least since my concerns are different from the DL rule cluster
<bijan> That's the norm
sandro: I'd assume it's enough to be a member of one WG.
<josb> at most 4 people? 2 from each WG?
<some discussion of who would be interested>
Chris: Shouldn't be too big.
<bijan> Is the goal to produce a document?
ACTION on Chris to talk to OWL Working Group Chairs, Alan and Ian
<josb> I'd say, yes
<Hassan> I suppose so Bijan (re: producing a document) - how else can it be?
Chris: will report next week
josb: In this case, Current RDF and OWL compatibility document would just be a RDF compatibility document.
<ChrisW> ok, bye
csma: In which case, this document is almost finished. (But we do have to note the change in document somewhere.)
... Action review
ACTION 389 on Paula has been done.
ACTION 382 on Sandro to report any critical -path ssues related to extensibility --- due next week.
ACTION 372,373,375,382 on Sandro -- also due next week
ACTION 349 on Dave to write up a use case for membership formulae -- done
<josb> ?item[oftype -> eg:HardwareType^^rif:iri]
<josb> or oftype(?item, eg:HardwareType^^rif:iri)
<josb> +1 this is indeed not a use case for the membership formulas
<Discussion of Dave's use case, and whether this example is artificial, to the point, etc. Expand.>
Dave: Axel's use case is neutral: doesn't argue for having a RIF member-of
csma: because could equally well use type-of
... so, we still don't have a use case arguing for a single membership formula.
... that is use case for having one single way for representing different types of membership.
harold: we have to view this in conjunction with classification as well.
... look at slotted extensions, which have membership and classification.
csma: we don't have use cases for classification formulae.
igor: are we making the same mistake as we did in Core? Should we leave all these elements in BLD, and then define various profiles = subsets?
... easier to define various profiles than to define extensions.
csma: But the question is: does anyone need these even in BLD?
igor: Seems like a basic construct.
csma: But not in rules languages. The question is --- where in rules do you need to assert or test something about classiciation?
igor: to me, seems like a nice bridge between rules languages and DL languages.
<Hassan> In a way, Igor is saying that rules and data models are independent - and I agree : they are orthogonal
<LeoraMorgenstern> I could imagine this coming up when doing marketing When developing new banking products, e.g, one would want to see if it can be classified in various ways ... e.g., finding out if there is a class that can be considered both a class of savings product and a class of investment vehicles
<markproctor> in Objects forward chaining engines tend to match against a hierarchy. So if someone does Collection() it'll match List, ArrayList, LinkedList etc. but thats as far as I know it goes.
<csma> Mark Proctor
MarkProctor: It seems one would need to check membership rather than classification
<csma> (to jeff)
<JeffP> thx, csma
sandro: Michael feels checking classification is necessary; should convince csma
hassan: no difference, conceptually.
<josb> in RIF, there is a difference
hassan: can do with only classification, which is more general.
<josb> (in OWL there is not)
hassan: membership is equivalent to singleton being a subclass.
<Harold> Hassan, because we are intensional here, a # S could be reduced to Nominal(a) ## S.
<markproctor> I don't think you would want to say match X if its a subclass of Y. as that information is implicit in your model.
<csma> rrsagent ;ake record public