W3C

- DRAFT -

RIF F2F6 June 3

26 Jun 2007

Attendees

Present
F2F-Meeting, Mike_Dean
Regrets
Chair
SV_MEETING_CHAIR
Scribe
GaryHallmark, agiurca, Dave Reynolds, PaulVincent, Igor Mozetic, Hassan, Harold, Benj

Contents


<sandro> mdean, do you want us on Zakim?

<sandro> Hassan, the EBNF on the asn07 (not asn06) page is more the direction I think it should go. http://www.w3.org/2005/rules/wg/wiki/asn07

<GaryHallmark> Scribe: GaryHallmark

<scribe> ScribeNick: GaryHallmark

Sorts

Chris: 4 ideas about what sort means
... problem that "1"^^String = "1"^^int which seems wrong

rdfs: resource is top sort
... much confusion about whether "1" should be in quotes

<csma> Hi mike!

<mdean> good morning

sandro: in rdf, ^^ is a mapping not a sort

chris: rif:iri as a sort was not understood

<sandro> (that is, the thing after the ^^ is a datatype, which identiies a mapping from a lexical space to a value space.)

chris: sorts are sets of things in the domain of discourse
... rif:iri is the set of all things that can be referred to by iri (uri) consts

Francois: so a sort is a pointer?

chris: no

sandro: its the universe

Francois: so it IS a concept of pointer

chris: no sorts are sets in the D of D
... so we will call it rif:resource
... proposed: rename rif:iri to rif:resource

francois: the denotation mechanism should not be a sort

chris: why sorts at all?
... straw poll may not be valid because of poor common understanding
... sorts should convery info about primitive datatypes (most languages have such)
... need to differentiate predicates, individuals, and functions
... e.g. just quantify over the individuals
... need function signatures (esp. for builtins)
... sorts are static, enable static type checking
... sort cannot be in rule conclusions

josb: sorts are constants and therefore cannot be derived

francois: sorts could be called "type annotations"
... whether or not they are constant is an arbitrary choice

<josb> the point is that a sort has a *fixed* set of constants; one cannot derive the fact that a constant is of some sort

csma: the sorts to which a constant belongs cannot be derived

<josb> unless the constant is in this fixed set

<sandro> Chris's four motivatations for sorts:

chris: primitive sorts are disjoint

<sandro> 1. primitive datatypes

<sandro> 2. predicates, individuals, functions (eg "just quantify over individuals")

<sandro> 3. function signatures, for buildins

<sandro> 4. enable static type checking, compile-time analysis

chris: not a "multi-sorted logic"
... for uniformity, everything has a sort
... if not primitive, then sort is rif:resource
... note that predicates also have sort rif:resource

francois: is it possible to define new sorts?

<csma> Example: P^^rif:ressource(Chris^^rif:ressource)

<sandro> Francois: big design choice -- can users add new sorts beyond the primitive data types?

francois: and would user defined sorts be subsorts of rif:resource?

<sandro> Francois: And if you say "no", I say "Why Not?"

chris: we agreed not to tackle data modelling, and user-defined sorts come close

<agiurca> rif:resource sort consist of predicates, functions and individuals?

<sandro> Chris: but this gets dangerously close to using sorts to define data modeling, which RIF-WG doesn't want to do.

chris: how are sorts and signatures related?
... translators can reasonably be expected to understand primitive sorts and builtin signatures
... limit overlap of sorts/sigs and datamodelling to builtin signatures/primitive sorts

<sandro> Chris: there will be some overlap between our sort mechanism for handling primitive datatypes, and the App Data Model facility. We'll try to minimize that.

<sandro> Chris: We're trying to avoid using sorts for user's data models.

francois: if rif:resource includes primitives, may have problems

<sandro> Francois: two problems: the Resource source which is a union (1=1 issues); 2: if we use XML Schema datatypes, which might have trouble because some of those are "derived" datatypes.

francois: maybe should forbid xsd derived datatypes

<sandro> Chris: It's not "forbid" -- it's which ones we require. Don't require the derived types.

francois: if no user-defined datatypes (e.g. telephone number), very strong restriction
... then people will try to write rules to check email syntax, and thats not what deduction is good at

<sandro> Francois: things like checking syntax of e-mail addresses should be done at the sort level, not the rule level.

<agiurca> should RIF allow for user-defined datatypes like EmailAddress?

<sandro> Francois: Just use the XML Schema notion of types as our sorts.

chris: we do not want rif core implementors to have to implement too much

hassan: 2 kinds of sorts should not be confused

sandro: why not use a single kind of sorting mechanism

<agiurca> user-defined sorts (such as EmailAddress )will be defined by means of rules?

<sandro> Francois: We need to have a way to convey the constraint that something is an e-mail address

<sandro> csma: Why not say that in the attached XML Schema for your data

<sandro> +1 csma

chris: maybe you could define syntax of email addr in xml schema and refer to it

<sandro> csma: It's not inside rif.

<DaveReynolds> -1 to csma, you then have different mechanisms for long from say short, we are introducing an asymmetry which seems worse than the asymmetry that sorts is purported to get round

<JeffP> josb: we need a reference for external data model

<sandro> Ah -- yes, DaveReynolds I wasn't agreeing with that. I want ONE mechanism for type checking.

<JeffP> csma: implementing RIF only requires supporting of some XMLS datatypes

<JeffP> scribenick JeffP

<JeffP> \scribenick JeffP

<DaveReynolds> ScribeNick: JeffP

<sandro> Gary: The proposal Chris described means that if I have an e-mail address in my ruleset, I can only say it's an xsd:string, I can't say it's an e-mail address.

<sandro> csma: you just have to wait until we have the data-model reference mechanism.

Michael: defined datatypes are sorts

FrançoisBry: good to have user-defined datatypes

<sandro> DaveReynolds: so is there a fixed set of types or not?

<sandro> Chris: (writing on board) "RIF will not invent yet another schema language"

<sandro> unspoken answer from me_ there isn't one for type signatures of functions and predicates.

ChrisW: why should we introduce yet another schema language to handle datatypes

Gary: can we define people in XMLS?

Dave: RIF should have a static type checking? Not sure it is required

<sandro> DaveReynolds: Chris went through the list of motivations for sorts. I don't find them compelling. I don't see why the Interchange format needs static type checking.

<sandro> MichaelK: You're just conveying the type to me.

<sandro> MichaelK: sort information allows more efficent implementation.

DaveR: not convincing me

FrançoisBry: you cannot do ... if you don't have sorts

<sandro> Francois: the point is whether you want to attach to a term that it's an e-mail address.

<sandro> Michaelk:L which allows more efficient implementation.

Sandro: sort mechanism should not in Core

<sandro> Sandro: Everything I'm hearing suggests that sorts are not needed in Core.

Gary: people dont write rules about strings and integers

ChrisW: open issue: how do we share application data model?
... the proposal is NOT to invent another ADM

Sandro: this has to be the same thing as sorts

<sandro> DaveReynolds, which category are xsd:shorts

ChrisW: ADM and sort might overlap

sandro: I object to sorts

ChrisW: lets talk about sorts but forget ADM for a moment

<sandro> (if they are separate from ADM)

Gary: if we don't talk about ADM, it is hard to discuss sorts

<sandro> Gary: Right -- this is like trying to pick the drapes before I've bought the house. Until we have ADM, let's not work on sorts.

<sandro> DaveReynolds: we may still need something for "I want to quantify over predicates" ...

DaveR: can we have some more justification on the motivation on distinguishing predicate individual and functions

<DaveReynolds> More specifically, the justification for using sorts for this

ChrisW: why not use the same mechanisms

Markus: not convinced why sorts

<sandro> MarkusK: I'm also not convinced we need sorts for point two (quantifyuing over indiv vs pred etc.)

<MarkusK> Markus: differentiation between predicates, functions, etc. important for dialects, but the sort mechanism might not be needed to achieve this.

FrançoisBry: if don't have sorts, you lose something in translation

<sandro> Francois: If you have sorts, you can translate them out. But not the other direction. So the interchange mechanism should have sorts.

<sandro> sandro: that's my objection to it -- If we're going to have sorts, they should include the ADM.

<sandro> Dave: I'd much rather have uniformity in sort-ADM than in quantifiers.

ChrisW: that's not complicated

Sandro: can we have a one-page description for it

csma: can we use another term?

Chris: we haven't discussed the impacts on variables

csma: XMLS is not enough to cover sorts such as predicates, individuals, functions ...

<sandro> MichaelK: sorts imply sorted variables, and knowing which constants belong to which sorts.

<sandro> Chris: rules with sorts can be translated to rules without sorts, eg using guards

<csma> csma: why not define a type for predicates, one for functions etc as part of RIF ML schema

<csma> csma: and use that instead of sorts (if it makes sense)

<agiurca> +1 csma

if primitive datatypes are sorts how about unions of some sub-types of primitive datatypes

<sandro> Francois: You remove not only the possibility of static checking, you hurt the runtime efficiency a lot.

<sandro> Dave: So we could have a fixed set of three quantifiers, for the three sorts of variables.

<agiurca> and the sets of predicates, functions and individuals may not be disjoint

<sandro> Dave: So we steer clear of the sorts for datatyping

<sandro> csma: and we just have quantifiers over individuals over in core

<sandro> scribe: agiurca

sandro: we cannot discuss sorts without discuss application data model

<sandro> Sandro: there's no question sorts are not necessary. there's no question that sorts are useful. the question is how to combine/relate them to the ADM, and we can't settle that until we have ADM.

Fraoncois: XML structured datatypes can be used like FOL function terms

josb: aproposal to use XML Schema for ADM

Application Data Models

<DaveReynolds> Scribe: Dave Reynolds

<DaveReynolds> ScribeNick: DaveReynolds

Second session - discussion on Application Data Models

<josb> http://www.w3.org/2005/rules/wg/wiki/Arch/Data_Sets

Harold: in reference to frame proposals, comment on need to represent subclass relations, would need to bridge those to RDFS?
... sorts are needed to avoid combinatorial explosions, rules on the web will range over large domains which will cost

<sandro> scribe:PaulVincent

Dave covers Data_Sets wiki page content...

Dave: Rules need to reference a concrete data set (fact set published at some location and some local data)
... Need a reference in the RIF to the data set -- this is a metadata problem
... ruleset requires dataset is the metadata relationship: dataset named by URI does not mandate a web dataset
... see example on Wiki page for supply chain ruleset with 2 datasets referenced
... binding of rulesets to datasets is separate from representation of datasets

Ref: http://www.w3.org/2005/rules/wg/wiki/Arch/Data_Sets

Christian: qu: is there 1 or several specific external dataset description languages? or should this be open?

Dave: per this being an architecture issue: core could specify some models but be extensible

<sandro> BenjaminGrosof: datal is just a fact-form ruleset.

BenG: fact model is extensible and could be an intermediate dataset language
... Sweetrules implemented this approach (import facts)

Dave: importing fact model is for data set as opposed to data model

Christian: there are multiple interests for different datamodel specifications eg OWL, XML, in RIF

<Harold> Dave, I wonder how your notion of Data Models is related to Abstract data types (e.g. http://en.wikipedia.org/wiki/Abstract_data_type): in both cases refinement is central.

Gary: would ASN06 be a worthwhile neutral datamodel?

All: No

Vote: 3 would vote for XML schema

<Harold> Hassan just suggested that "Breakout on Abstract Syntax and Semantics" may be relevant here: http://lists.w3.org/Archives/Public/public-rif-wg/2006Nov/0025.html

Qu: restarting vote: specify your choice...

<sandro> Straw poll on first choice data modelling system: CLP, RDBM, RDFS (2), ODM (3), F-logic, XMLS (4), OWL-DL, OWL-Full (2)

Choices described (+Votes>1): CLP, RDBM, RDFS(2), ObjDataModel(3), FLogic, XMLS(4), OWLDL, OWLFull(2)

<mdean> +1 for OWL-Full

<sandro> RDBM -- "no standard notion"

<mdean> audio just stopped on the telecon bridge

Vote2: could live with: CLP (2), RDFS (6), FLogic (3), XMLS(8), OWLDL (5), OWLFull (7)

<ChrisW> mdean, did the volume drop to a low level or just go out?

{audio being sorted}

<sandro> mdean, Jos is redialing.

<ChrisW> (CSMA is not near the phone)

<mdean> went out suddenly, as if someone hit mute - thanks

<Hassan> Actually the ODMG (Object Databas Management Group) has published a formal ODM (http://www.odmg.org/)... -hak (a.k.a. the waffler :-)

<mdean> welcome back - i can hear again

Paul: does Obj Data Model include OMG ODM which includes RDF, OWL etc? [answer deferred]

Hassan/Christian: ILOG could be compliant with XMLS

<sandro> Sandro: What about XMLS+RDFS ?

<sandro> Gary: Pick one -- it's supposed to be a standard. I don't really want to implement both.

Christian: compliance to RIF cannot mean compliance to both RDFS AND XMLS

<Hassan> (regarding ODMG Object Data Model, see also http://www.odmg.org/oifml.pdf)

<DaveReynolds> Scribe: Dave Reynolds

<DaveReynolds> ScribeNick: DaveReynolds

[DIscussion on RDFS/OWL tradeoffs for data models]

<sandro> Sandro: I don't understand the tradeoffs between RDFS/OWL-DL/OWL-Full in this context.

Jos: if RDFS we know how to deal with it with rules

<sandro> Jos: with RDFS, we know exactly how to deal with it with rules.

Jos: but for OWL there are more issues to deal with

<agiurca> +1 jos

Benjamin: what would it take for people to support RDFS? There seem to a lot of systems supporting RDFS now (based on SemTech conferences)

<sandro> BenjaminGrosof: What it would take for people to support RDFS.... it's pretty straightforward -- I'm seeing a lot of uptake by vendors.

csma: But there is lots of legacy XMLS so if we only had RDFS these would need to be somehow translated

<sandro> csma: legacy data in xml schema

Benjamin: making a different point, barrier to *also* implementing RDFS, as well as XMLS, is not that great

<sandro> BenjaminGrosof: RDFS would not be a big burden beyond XMLS.

Markus: just need to consider what is core, if languages support RDFS they can do that as an extension even if not in core

csma: agrees, the issue what you can assume is implemented

Markus: but do we need to make any mandatory, we have such a diversity of systems

csma: could you exchange some rules w/o any data model? ans: yes

Sandro: issue with just XMLS is that it just tells you the syntax, doesn't say what is a class or semantic relationships

csma: wants to follow up Markus' suggestion

Benjamin: so that would be treating the datamodels as extension points, dialects could add required models

<sandro> poll: who could live with no ADM in core: 11

Straw poll: who could live with no mandated data model in core? 11

csma: would still want to vocabularly for saying which model you are using would still be defined, even if which models you support are optional

Sandro: only have to recognize the ones you have to implement

<sandro> Jos: the crucial point is to specify how RIF and the data-model interact.

Jos: the vocabulary can still be extensible, but for the defined ones we have to say exactly what the interaction between the rules and the datamodels is

<sandro> mkifer: RIF needs it own datamodel, to map these into.

Michael: need a datamodel *in* RIF since we have to map these external models into that

<sandro> csma: is that the slotted syntax?

csma: this is what the slotted syntax was intended to achieve?

<sandro> mikfer: yes, but it doesn't have all the datamodel part of it.

Gary: agree need some sort of datamodel in core and then map everything into it

<sandro> Gary: right, so it's all up to the translator.

<sandro> many: but then how to do you know everyone is mapping the same way?

<sandro> Gary: Oh, right -- for external data, not flowing through the translator, we need to label ADMs.

Jos: in typical use you wouldn't translate the data model

<Hassan> Latest standard ODMG Object Data Model standard document is available at http://www.omg.org/docs/omg/04-07-02.pdf

Benjamin: the issue of how different peoples mappings agree can be partly met but the use of the metadata, a little metadata can go along way and build up by practice

<sandro> BenjaminGrosof: (1) does their mapping agree with my mapping? we thought about that a lot in SweetRules. A little metadata. A URI for the translation method.

<sandro> BenjaminGrosof: (2) we as a committee -- can't do these mappings. they are much too much work.

<sandro> I am confused about RIF having it's own canonical data model.

<sandro> DaveReynolds: How do you reconcile the idea of RIF having its own data model to "RIF will not invent yet another schema language"

csma: Not a new dat model in RIF but how the external data model *links* to the rules

Harold: there is a problem using XMLS (unencoded, so that application validators can be directly used) how to do access the XML structure, treat only as ground terms?

csma: Isn't there a middle ground like slotted syntax?

Jos: re: data model in RIF and map that to external models; advocate bottom up approach based on what we want to represent and see how we can map

Sandro: charter puts some of these issues into phase 2 (data models which don't go through the translator) [scribe didn't capture this accurately]

[Discussion on how current rule systems handle this]

Gary: we map object models into a form of slotted notation - need slots and lists

Hassan: in prolog separate edb and idb, raw data (edb) in XML/RDFS/whatever is not a problem
... when come to rules, the issue of variables arises. The problems is not for the dataset but for the rules.

<Harold> Visual Prolog (http://www.visual-prolog.com) has user-definable algebraic data types, which are relevant to supporting different appliction data models in RIF.

Paul: problem with rules being built on top of data models. If I represent some facts in the rules then that has to tied to the data model for data sets.

csma: if all are optional then still have bilateral agreements between parties wanting to exchange

Paul: doesn't that cause and explosion of RIF versions?

Sandro: but it is a linear growth, not an explosion

<sandro> (you just need one translator per language)

Harold: could have abstract data type mechanisms, c.f. constructors in Visual Prolog

Jos: make more concrete, he has proposed RDFS mapping, could someone do same for XMLSchema?

<Harold> s/ abstract data type/ (constructor/signature-restricting) algebraic data type/

<agiurca> http://markproctor.blogspot.com/2007/06/w3c-rule-interchange-format-for.html

csma: could build on the proof of concept work done by Philippe and Mark Proctor

Gary: this is passing data by reference which is not ph1 as Sandro says, focus on passing data by value

Benjamin: are we clear on difference between data model and ontology, when we talk about OWL/RDFS we are talking about onotlogies right. Jos: yes

<ChrisW> jos - can you paste a pointer to your proposal

<josb> http://lists.w3.org/Archives/Public/public-rif-wg/2007Jun/0002.html

Benjamin: can capture a lot of OWL directly in rules

<josb> http://lists.w3.org/Archives/Public/public-rif-wg/2007May/0077.html

<sandro> BenjaminGrosof: just translate the relevant section of OWL to RIF and send it along with your RIF.

<Harold> In many other Prologs (other than Visual Prolog) there is no application-fixed restriction on constructors/signatures. XMLS kind of reinvented Turbo/Visual Prolog's grammar-like mechanism to restrict the legal structured terms for different applications.

Paul: standardizing existing rule models against existing data models, focus on things that help adoption

csma: looking for volunteer to look at xmls mapping case to identify what is missing from core

<sandro> Jos: I have the feeling that, despite all this talk of needing XMLS, no one knows exactly what it would mean for us to use XMLS.

Gary happy to take an action to explore

Sandro: this is much less important than the XML syntax in terms of where we are trying to get to next

<scribe> ACTION: GaryHallmark to draft a list of the top few difficulties in mapping XMLS to what we have now

<rifbot> Sorry, couldn't find user - GaryHallmark

<scribe> ACTION: Gary to draft a list of the top few difficulties in mapping XMLS to what we have now

<rifbot> Created ACTION-298 - Draft a list of the top few difficulties in mapping XMLS to what we have now [on Gary Hallmark - due 2007-06-10].

next F2F

<IgorMozetic> scribenick IgorMozetic

<ChrisW> scribenick: IgorMozetic

<ChrisW> Scribe: Igor Mozetic

our charters runs

for 6 more months

if we don't reach recommendation in this time it is the

question of extending or not the WG

csma: extending the charter is easier then rechartering
... but we should reach at least the last call before recommendation

all this concerns just Phase I

<Harold> http://www.w3.org/2005/10/Process-20051014/tr#last-call

sandrom: last call means that we beleive that we are done

Paul: do we have a roadmap?

<MarkusK> s /sandrom/Sandro/

<sandro> Chris: Does it seem reasonable to expect we'll be at last call by November?

<sandro> Dave: It seems like a strech. I'm not willing to write a blank check to do whatever it takes to reach that.

some don't believe that we can reach the last call by November

nobody is willing to go to F2F every month

Hassan: we can summarize what we have done and specify precisely
... what else is to be done

BenG: a lot more technical work is needed
... proposes starting extension of the charter now

Sando: not likely to succeed

Sandro: decison about extension is done by technical committe
... some implementations would be very helpful
... Phase II extensions could be done within incubator groups

csma: proposals for next F2Fs
... ILOG (July, Aug), New York (IBM, StonyBrook) Sep-Oct
... Boston (Aug, Oct), Boston (5-11 Nov) W3C Tech Plenary

<Harold> Let's see how to avoid clashes:

<Harold> ISWC 2007: November 11 (Sunday) - 15 (Thursday), 2007, Busan, Korea

Sandro: if TechPlenary then Nov 5-6

nobody proposes a meeting before September

csma: no F2F on weekend

<Harold> RuleML-2007: October 25-26, 2007, Orlando, Florida, International RuleML Symposium on Rule Interchange and Applications, http://2007.ruleml.org

proposal week starting 20 August (2 days): 4 cannot make it

week 27 August: 3 cannot make it

week 3 Sept: 7 cannot make it

week 10 Sept: 3 cannot make it

week 17 Sept: 3 cannot make it

week 24 Sept: 5 cannot make it

<Harold> Summer School Reasoning Web 2007: 3 to 7 September 2007, Dresden, http://reasoningweb.org/2007

<Harold> OMG Technical Meeting: September 24-28, 2007, Jacksonville, FL, http://www.omg.org/news/schedule/upcoming.htm

Options weeks of27 Aug or 17 Sept

week 27 Aug: 7 preferences

week 17 Sept: 6 preferences

4 have no preferences

action on csma: send an email to the WG, answers in two weeks

who would come to a 3 days meeting: all, 6 preferences for 3 days, 4 preferences for 2 days

<sandro> nobody said they would not come because it's 3 day meeting.

F2F8 could be at the Tech plenary

<sandro> Anyobody couldn't make 5-6 november, Boston....?

<sandro> Hassan -- I can't make it to meeting in US.

dates are 5-6 Nov, Boston: 1 cannot make it (Hassan)

week 17 Sept: 6 cannot make it in North America 1 cannot make it in Europe

<Hassan> Scribenick: Hassan

<IgorMozetic> scribe: Hassan

<Harold> http://www.w3.org/2005/rules/wg/wiki/Core/Slotted_Conditions

Harold presenting on Slotted Syntax

Using ASN.06 to express rule conditions using slotted syntax

Uniterm can have args expressed either as list of terms, or list of attribute/value pairs

Cannot mix positional subterm notation and slotted subterm notation

Subclassing is supported

Instanciation is supported

Frame extends the above with attributes that can have structures or even variables

Classification states instance/class or subclass/superclass relations

<MarkusK> Jos: I think that having CLASSIFICATION as part of slotted syntax contradicts our goal of not defining schema language features in RIF Core.

No disjunction nor negation in the frame notation, but can be simulated at the formula level

<MarkusK> Jos: I object to the having classifications as part of the language.

<sandro> Jos: my objection is to have CLASSIFICATION at all in the language. we should just use the semantics of the data model. It contracits "RIF will not invent yet another schema language"

Michael: the semantics of the proposed slotted syntax expressed "instanceof" and "subclassof" as relations

MarkusK: I agree with Jos that this special form of classification has nothing to do either slotted notation

<agiurca> +1 to MichaelKifer solution

<PaulaP> +1 to Markus' comment

Christian: what about a syntax that allows querying an external data model using the semantics of an external language?

<MarkusK> s /has nothing to do either slotted notation/should not be part of the core. It also seems that this question is unrelated to whether we want slotted syntax or not./

Jos: you commit to a data model with this classification

<msintek> +1 for Markus' comment and Jos proposal to use slots for rdf:type etc -- this is then exactly TRIPLE (http://triple.semanticweb.org/)

Jos: this is too weak for RDF

Markus: why do we need this extension in the core?

Christian: as a device to support RDF.

<MarkusK> Chris: the objection of Jos was that typing constructs create a new schema language in RIF.

<MarkusK> csma: but we could restrict typing/subclassing statements to rule bodies, so as to only allow querying of existing schema.

<sandro> csma: I'm imagining that "instance" and "subclass" are common across all schema languages.

msintek: RDFS has subproperty and the proposed notation does not - isn't this a problem?

<sandro> +1 MichaelS handle it all with slots.

<MarkusK> msintek: we implemented RDF(S) suport in our rule system TRIPLE, and explicitly decided against these built-in # and ## operators.

<sandro> BenjaminGrosof: Right. You import an axiomatization.

BenjaminGrosof: why not say "ontologies" rather than "Data models"? It seems to me that ontologies are what we should use.

Gary: the proposed notation is ok, but not for constants.

<sandro> Gary: I like this if the types are constants. But not if they are terms or non-ground.

Jos: we spoke about classification rather than the slotted notation
... we need to discuss the slotted notation and the frame syntax as well

<PaulaP> +1 to Jos

<MarkusK> +1 Jos

Christian: does the slot notation without clasification work?

Jos: yes
... I have additional objections ...
... I dislike having both slotted terms along with frames - this complicates things.

Michael: there is a mapping between the two - but it is complicated

<sandro> Harold: Frames have a "subject", but slotted terms do not. There is a mapping between them, but it's very complicated.

Coffee break - reconvene in 30 mins

<sandro> Chris: three separate proposals

<sandro> Chris: frames, slotted predicates, classification.

<Harold> Discussion about Slotted Conditions

<sandro> Chris: semantics is: objects with slots and values, where slots are just binrary predicates.

<sandro> scribe: Harold

Chris: What about only having the Frames part without CLASSIFICATION, not the Slotted Uniterm part?

<sandro> PROPOSED: Add Frames to RIF Core (objects with slots and values, where slots are just binrary predicates), roughly as described in http://www.w3.org/2005/rules/wg/wiki/Core/Slotted_Conditions. We'll decide about the classification and slotted-predicates separately.

<sandro> RESOLVED: Add Frames to RIF Core (objects with slots and values, where slots are just binary predicates), roughly as described in http://www.w3.org/2005/rules/wg/wiki/Core/Slotted_Conditions. We'll decide about the classification and slotted-predicates separately.

<sandro> (19-0-0)

Discussion about Extensibility of RIF Core

<sandro> Hassan: sorts and unary predicates are identical semantically, but pragmatically they are different.

Chris: Also brings us back to sorts.

<sandro> Chris: every object in domain has a sort.

Igor: Difference between sorts and data types?

Francois: Data types (a la programming languages) are exactly like sorts.

Chris: Where do sorts fit into extensibility?

MichaelK: Little connection, although you can add more sorts for extensibility.
... more important for extensibility are the signatures.

<sandro> Mkifer: signatures are orthogonal. could do it with one sort: sort Universe x Universe x Universe, or whatever.

MichaelK: Eg, in atomic formulas, for every integer constant, you can attach an int sort in the signature.

<sandro> Mkifer: signatures might be defined differently in different dialects. you might recognize them as used.

<sandro> MK: if you have more than one sort, then the signatures use it. Distinguishing between predicates, functions, and individuals is done by signatures.

Jos: Why sorts? To show that predicates, functions, constants are interpreted in different domains.
... ensure that they (at least:) can be interepreted in different domains.

MichaelK: Dont need sorts for this.

Francois: Untrue.

MichaelK: Assumed every symbol has one sort.

Jos:

E.g.: a:const, p,q:pred

MichaelK: Yes, need also sorts.

Jos: There is a resolution that all symbols should be interpreted such domains.

Sandro: In code you can distinguish functions, predicates, but in the semantics?

MichaelK: You need sorts to prevent all individuals collapsing into one element (when you go to FOL).

<sandro> Sandro: I agree you need a way to quantify over only individuals.

Chris: Dialects could define sorts for extensibility.

Benjamin: Should we not accommodate FO languages early on?

MichaelK: Already planned.

Benjamin: Already make it a dialect?

Sandro: Default quantifier should be over individuals.

Dave: In RDF there are such quantifiers.

<sandro> Dave: We don't need quantification over anything other than individuals. RDF just translates into frame-slots.

<Benj> Benjamin starts scribing

<sandro> scribe: Benj

Chris: how can we define and record some progress on this sorts aspect of

extensibility?

Gary: what would be the sorts lattice corresponding to this [i.e., first order restriction]?

<sandro> Chris: sorts include: Ind, Pred, Func, int, string ---- and you may or may not let them overlap.

Chris: drew a diagram of three top-level sorts -- INDividual PREDicate FUNction

then also with Int, String, etc. as additional type sorts

then one can specify/declare whether PRED and IND are disjoint, whether Int is a subsort of IND, etc.

Chris: Sorts provide: (1.) static checking; and (2.) restricted quantification

<Francois> bye.

Sandro: I presume we're talking about sortedness where constant occurrences aren't declared individually, but rather explicitly specified only once per document, eg up top sort of like a declaration

MichaelK: related to, but distinct from, the sorts are: signatures

<sandro> Sandro: I am emphatically not okay with saying that the denoatation depends on the pair (symbol, sort) ie overloading.

Chris: is a sort a set of elements in the domain?

MichaelK: no, it's a set of symbols that then are interpreted as sets of elements in the overall domain, e.g., as separate domains

<Francois> In RIF there is a curse with sorts...

(general: discussion on overloading)

Chris: does a pair of a symbol and a sort uniquely determine an element in the domain of interpretation?

<Harold> Maybe the confusion with Jos' example of "1" possibly being sorted as integer and string is due to the syntax "value"^^sortname

<Harold> in http://www.w3.org/2005/rules/wg/wiki/Core/Positive_Conditions.

JosB and MichaelK and Francois: yes, what's disallowed is the same such pair being non-functional in its interpretation mapping

<Harold> "1"^^int vs. "1"^^string.

Sandro: Fido being both a cat and a dog is incompatible with RDF

Hassan and others: overloading is routine in many programming etc. languages, I sent an example about this earlier

Chris: now I don't know how to proceed -- ?

MarkusK: could make the "^^cat" be part of the constant name in

"Fido^^cat"

Benj: it's like "Fido the cat" vs. "Fido the dog"

Sandro: in the Semantic Web, we want URI's to denote the same thing

DaveReynolds: we could repeal our earlier resolution, and have the Core be first-order in style with predicates and functions/individuals be disjoint, and punt the single-sort case/semantics to an extension not the Core (of RIF)

Chris: so we have two options about how to proceed

1st is to backoff from sorts -> disjoint sorts

MichaelK: if we do, then we lose the ability to deal with RDF's generality via the one sort

<MarkusK> s /one sort/overlapping sorts/

Chris: 2nd is how we have been proceeding before this

DaveReynolds: we may have to back off to be able to achieve a Core

Sandro: if the constants are URI's then I object to the approach of "ConstnameURI^^sort"

Benj: is it legal to view "...fido^^cat" as a URI?

<Harold> Sandro seems to have a problem with "http://example.fido"^^cat vs. "http://example.fido"^^dog

Francois and others: No, you'd escape it , as in Harold's comment immediately above

JosB: the best practices committee of the web has said that a URI should denote one thing in the world

Chris: should we require the interpretation that if a URI belongs to more than one sort, it's still the same thing in the interpretation into the domain

Francois: URI's don't belong to these categories, they can't receive sorted notations

MichaelK: no [... missed the rest]

<GaryHallmark> michael: sorts are not in the domain of discourse

MichaelK: sorts are not in the domain of discourse, unlike unary predicates; they are not sets of things in the domain of discourse but rather are outside of it and indicate such, plus have some other special characteristics like variables and things

MichaelK and Benj: URI's are often used just as essentially local names or strings [not further dereferenced or existing] so we want to be able to declare their sorts

Sandro: I second Dave's suggestion to back off sorts

Francois: I suggest not to consider sorts any longer, and for individual constants/symbols then say they are expected to behave like in [?] XML-S

MichaelK: for anything that is proposed, I want to see written down how it behaves

Christian: add typed literals and typed variables to a proposal

<sandro> PROPOSAL-DER: switch back from OS to DS, have only one sort, have typed literals as per RDF semantics.

<sandro> PROPOSAL-FB: DER + typed variables.

DaveReynolds: don't try to permit same symbol to be interpreted (as in general RDF) both as a predicate or (non-ind) function and as an individual

<sandro> Michael: I don't understand PROPOSAL-FB. I think I understand PROPOSAL-DER.

DaveReynolds: I'm proposing that we would have an extension to deal with sorts so as to be able to do sorted unification for efficiency etc.

<Harold> Notice that in http://www.w3.org/2005/rules/wg/wiki/Core/Positive_Conditions "Multisorted RIF Logic" was initially called something like "Multisorted Extension", sorts were added later, so we could still regard sorts as a dialect.

Someone: RDF semantics spec has types, we can take similar approach

<sandro> DaveR: I realize we're giving up on semantics as being neat extensions

<sandro> Jos: We never had that.

MichaelK: there's an issue wrt relationship of extensions to the Core -- they won't really be extensions logically speaking

i.e, straight extensions in the strict logical sense

DaveReynolds: I'm proposing let's do the first useful bit, as dialect 0, rather than a fully general foundation for everything we will want to do -- which we can do later

<sandro> Scribe: Harold

Christian: First useful bit that is extensible.

Dave: Primary thing is that everything is in the same domain of discourse. We dont give this up. Different sort of thing as "Do we add production rules?" etc.

MichaelK: Problem that it will be difficult for people to understand.
... Like writing a 10-page paper (with sorts) than a 5-page paper (without sorts) .

Benj: Not be technically 'hasty'.

Chris: A way to move. Proposal with syntax and semantics.

<scribe> ACTION: MichaelK, Jos, Harold: Remove overlapping sorts, don't mention sorts, handle datatypes as in RDF.

<rifbot> Sorry, couldn't find user - MichaelK,

Gary: Keep signatures?

MichaelK: Why "^^", not just "^"?

Sandro: "^" is shortcut for forward arrow in N3.

<sandro> ACTION: Michael to Remove overlapping sorts, don't mention sorts, handle datatypes as in RDF.

<rifbot> Sorry, amibiguous username (more than one match) - Michael

<rifbot> Try using a different identifier, such as family name or username (eg. merdmann, mkifer, msintek, uscholdm)

<sandro> ACTION: Mkifer to Remove overlapping sorts, don't mention sorts, handle datatypes as in RDF.

<rifbot> Created ACTION-299 - Remove overlapping sorts, don\'t mention sorts, handle datatypes as in RDF. [on Michael Kifer - due 2007-06-10].

<sandro> ACTION: Jos to Help Michael Kifer remove overlapping sorts, don't mention sorts, handle datatypes as in RDF.

<rifbot> Sorry, amibiguous username (more than one match) - Jos

<rifbot> Try using a different identifier, such as family name or username (eg. jdebruij, jderoo)

<sandro> ACTION: Jdebruij to Help Michael Kifer remove overlapping sorts, don't mention sorts, handle datatypes as in RDF.

<rifbot> Created ACTION-300 - Help Michael Kifer remove overlapping sorts, don\'t mention sorts, handle datatypes as in RDF. [on Jos de Bruijn - due 2007-06-10].

Chris: Wrap-ups:

<sandro> ACTION: Harold to Help Michael Kifer remove overlapping sorts, don't mention sorts, handle datatypes as in RDF.

<rifbot> Created ACTION-301 - Help Michael Kifer remove overlapping sorts, don\'t mention sorts, handle datatypes as in RDF. [on Harold Boley - due 2007-06-10].

We did not cover during this meeting:

* Test cases

* Implementation

* RIF arch

* Phase 2 reqs

* Next drft use case document

* Builtins

* Datatype for lists.

Hassan: Let's carry out real exchange with two languages/systems.

Sandro: Driven by the spec.

Hassan: Rather than 'lofty goals'.
... otherwise dont see how to proceed.
... eg Jena <--> Prolog

Chris: Find people to take some of these open things as actions.

Christian: Already started.
... just look what we add and see how to progress.

Chris: Anyone else interested in test cases for RIF.

Benj: What about existing test cases and adapt to RIF?

Christian: Already started for MISMO.

Hassan: Working on scheme that could come into RIF.

Chris: What would translator get? test cases?
... specifying methodology.

<agiurca1> if we have a RIF XML Schema then we can try translators

Hassan: Would like to easily retarget 120 rules that describe JRules to RIF.
... just by changing annotations.
... will be ready hopefully for next f2f.

Chris: Anyone work with Dave on test cases?

Benj: I'd be willing to help; Common Rules and Sweet Rules are closest. Round-tripping.

<sandro> ACTION: Benjamin to work with Gary and DaveR on Test Cases approach

<rifbot> Created ACTION-302 - Work with Gary and DaveR on Test Cases approach [on Benjamin Grosof - due 2007-06-10].

<DaveReynolds> Current sketch page for test cases is: http://www.w3.org/2005/rules/wg/wiki/Arch/Test_Cases

Chris: Arch document. Realistic deadlines. Most actions done.

<sandro> Next telecon is June 12

Jos: Fine.

Chris: Start semantics section of Arch document till next telecon.

MichaelK: Need to work on Core (without sorts).

The Action on modular Condition Language is put on hold.

Chris/Christian: Reqs on Phase 2 by Paula need to be reviewed.

<sandro> ACTION: csma to put Arch on next telecon

<rifbot> Sorry, couldn't find user - csma

<sandro> ACTION: christian to put Arch on next telecon

<rifbot> Created ACTION-303 - Put Arch on next telecon [on Christian de Sainte Marie - due 2007-06-10].

<sandro> ACTION: Benjamin to review Paula's phase 2 requirements and discuss

<rifbot> Created ACTION-304 - Review Paula\'s phase 2 requirements and discuss [on Benjamin Grosof - due 2007-06-10].

<sandro> ACTION: Gary to review Paula's phase 2 requirements and discuss

<rifbot> Created ACTION-305 - Review Paula\'s phase 2 requirements and discuss [on Gary Hallmark - due 2007-06-10].

Chris: Fixing Abstract Syntax

Christian: Some things seem to hamper extensiblity.

<sandro> ACTION: Christian to write up his suggestions for abstract syntax

<rifbot> Created ACTION-306 - Write up his suggestions for abstract syntax [on Christian de Sainte Marie - due 2007-06-10].

<sandro> ACTION: Sandro to write up his suggestions for abstract syntax

<rifbot> Created ACTION-307 - Write up his suggestions for abstract syntax [on Sandro Hawke - due 2007-06-10].

<sandro> ACTION: Harold to collaborate with Dave on changes to absyn resulting from PROPOSAL-DER

<rifbot> Created ACTION-308 - Collaborate with Dave on changes to absyn resulting from PROPOSAL-DER [on Harold Boley - due 2007-06-10].

Gary: completed action from yesterday on Sandro's syntax page: fully striped.

<sandro> ACTION: Sandro work on unified strawman proposal for asn->xml system

<rifbot> Created ACTION-309 - Work on unified strawman proposal for asn->xml system [on Sandro Hawke - due 2007-06-10].

<sandro> ACTION: Gary work on unified strawman proposal for asn->xml system

<rifbot> Created ACTION-310 - Work on unified strawman proposal for asn->xml system [on Gary Hallmark - due 2007-06-10].

<sandro> ACTION: Hassan to work on unified strawman proposal for asn->xml system

<rifbot> Created ACTION-311 - work on unified strawman proposal for asn->xml system [on Hassan Ait-Kaci - due 2007-06-10].

Chris: Builtins: Just picking them?
... others want to add some?
... or take some out?

<sandro> ACTION: Christian to get Philippe's comments on the list of built-ins send in English

<rifbot> Created ACTION-312 - Get Philippe\'s comments on the list of built-ins send in English [on Christian de Sainte Marie - due 2007-06-10].

<scribe> ACTION: Igor to look to into extending/removing builtins.

<rifbot> Created ACTION-313 - Look to into extending/removing builtins. [on Igor Mozetic - due 2007-06-10].

<sandro> ACTION: Jeff to try to propose a strawman for a collection/list/sequences structure/mechanism (Harold to help).

<rifbot> Created ACTION-314 - Try to propose a strawman for a collection/list/sequences structure/mechanism (Harold to help). [on Jeff Pan - due 2007-06-10].

Christian: For production rules we need the head of rules to allow actions.

<sandro> Implementation Guidance for translated from Core to PR systems.....

<sandro> Implementation guidance for translating from Core to PR systems.....

<sandro> ACTION: Paul to start discussion on implementation guidance for translating from Core to PR systems.....

<rifbot> Created ACTION-315 - Start discussion on implementation guidance for translating from Core to PR systems..... [on Paul Vincent - due 2007-06-10].

Summary of Action Items

[NEW] ACTION: Benjamin to review Paula's phase 2 requirements and discuss
[NEW] ACTION: Benjamin to work with Gary and DaveR on Test Cases approach
[NEW] ACTION: Christian to get Philippe's comments on the list of built-ins send in English
[NEW] ACTION: christian to put Arch on next telecon
[NEW] ACTION: Christian to write up his suggestions for abstract syntax
[NEW] ACTION: csma to put Arch on next telecon
[NEW] ACTION: Gary to draft a list of the top few difficulties in mapping XMLS to what we have now
[NEW] ACTION: Gary to review Paula's phase 2 requirements and discuss
[NEW] ACTION: Gary work on unified strawman proposal for asn->xml system
[NEW] ACTION: GaryHallmark to draft a list of the top few difficulties in mapping XMLS to what we have now
[NEW] ACTION: Harold to collaborate with Dave on changes to absyn resulting from PROPOSAL-DER
[NEW] ACTION: Harold to Help Michael Kifer remove overlapping sorts, don't mention sorts, handle datatypes as in RDF.
[NEW] ACTION: Hassan to work on unified strawman proposal for asn->xml system
[NEW] ACTION: Igor to look to into extending/removing builtins.
[NEW] ACTION: Jdebruij to Help Michael Kifer remove overlapping sorts, don't mention sorts, handle datatypes as in RDF.
[NEW] ACTION: Jeff to try to propose a strawman for a collection/list/sequences structure/mechanism (Harold to help).
[NEW] ACTION: Jos to Help Michael Kifer remove overlapping sorts, don't mention sorts, handle datatypes as in RDF.
[NEW] ACTION: Michael to Remove overlapping sorts, don't mention sorts, handle datatypes as in RDF.
[NEW] ACTION: MichaelK, Jos, Harold: Remove overlapping sorts, don't mention sorts, handle datatypes as in RDF.
[NEW] ACTION: Mkifer to Remove overlapping sorts, don't mention sorts, handle datatypes as in RDF.
[NEW] ACTION: Paul to start discussion on implementation guidance for translating from Core to PR systems.....
[NEW] ACTION: Sandro to write up his suggestions for abstract syntax
[NEW] ACTION: Sandro work on unified strawman proposal for asn->xml system
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/06/26 13:27:16 $