RIF Telecon 10 Apr 07 -- 10 Apr 2007

<csma> Alex, can you scribe today, please?

<Francois> ??P1 is me.

yes

<csma> thanx

<csma> scribenick: StellaMitchell

<sandro> (I'll be a few minutes late.)

Admin

csma: next meeting, next Tues, April 17

PROPOSED: approve minutes from March 27

RESOLUTION: approved minutes from March 27 telecom

csma: any proposed amendments?
... (none)

Liason

csma: action review

action-268 complete

csma: any news from liasons?
... no news

Core

csma: action review

<josb> yes

action-271 complete

action-272 continued

csma: first item of technical design: issue 30, about rif:uri
... there has been email disucssion
... has this led to any agreement?
... michael kifier is not here
... jos, summarize?

<Harold> Hi, I was late so just joined first on the phone, then on IRC. Someone can tell zakim who I am?

jos: i talked with mk offline and no longer have any disagreement
... I thought doc was proposal for a dialect, but it is just basically a framework so it is ok to be more general

csma: but what is rif: uri?

<sandro> (sorry for being late)

jos: it is a sort, an iri written in normal form
... no additional semantic commitments
... dialects may introduce additional restrictions

csma: dave reynolds, any comments?

dave: discussion of whether they should be iri's
... wasn't sure about ???

jos: that would be specified in particular dialects?

csma: jos, do you consider this issue basically resolved?
... who would be the one to write the additional text on which everhyone would agree

jos: not sure that we need additional text

csma: the issue is a question re: what is definition of rif:uri
... so we need a written definition

csma: mk, who would write the text that will allow us to close issue-30
... WD1 currently refers to the issue

mk: what is the problem with the current text?

jos: it refers to an open issue

mk: is the syntax the same as rfc ?

<sandro> http://www.rfc-editor.org/rfc/rfc3986.txt

<ChrisW> RFC 3987 is the IRI RFC

csma: is it ok to not have any agreed upon definition of rif: uri

<sandro> http://www.rfc-editor.org/rfc/rfc3987.txt

mk: there is a definition, but we are not sure it's what we want

daver: on question of syntax, I did propose a phrasing

mk: i think you proposed that the rfc allows relative uri's
... and relative uris is just a shorthand

daver: normalizations and change references to iris

<Harold> An XML syntax for URIs/IRIs was discussed before: http://www.w3.org/2005/rules/wg/wiki/A.1.1_Basis%3A_Positive_Conditions_over_Bipartitioned_Constants

<DaveReynolds> http://lists.w3.org/Archives/Public/public-rif-wg/2007Mar/0133.html

csma: proposed resolution of issue-30 is that we remove sentence from WD1
... about open issue
... and inclused dave's proposed text

jos: in earlier doc we already had synax for iri, are people still aware of it?
... it was an attribute

<ChrisW> ^jos^harold^

jos: for RDF group was not sufficient to just reference rfc, so it might not be in our cas either

csma: that is about syntax

dave: reason for that is iri spec wasn't finished at that time
... difference ended up being in treatment of spaces

<ChrisW> 3987=IRI

dave: sparql was fine pointing to rfc 3987

mk: will we call them uris or iris. have we decided on iris?

harold: most people prefer iri; but i like uri or subset of iri

csma: any objection to using iri?

<josb> RDF, SPARQL use IRIs

chris: I don't understand consquences of the decision to use iri
... I don't know of anyone who actually uses them

sandro: concerned about market perception

<josb> +1 to Sandro; better to use IRIs, but call them URIs

<ChrisW> +1 to holding off on IRI vs. URI

sandro: most people still use "uri"
... uri and iri are mappable to each other
... so in that sense they are equivalent

csma: i agree with chris, so would rather be more conservative and use uri
... let's raise an issue about whether to use uri or iri

mk: but dave's formulation refers to iri

dave: people do use iri in rdf data
... so if we communicate that rif doesn't support iri, it would surprose people

mk: in rdf, do people use uri or iri?

dave: (didn't catch answer)

chris: how about if the text says "iri or uri"

<Harold> I wonder if the URI/IRI issue wouldn't be a (much) broader topic than for RIF or even the Semantic Web, perhaps for the Technical Architecture Group (TAG): http://www.w3.org/2001/tag/ (BTW, how do we liaise with the TAG?)?

chris: the name of the sort can still be "rif:uri"

mk: how about use uri now, and say that in future rif might change to iri

csma: still an issue

sandro: i agree with dave that semantic web community expects iri
... people are used to iris, they just don't call them iris
... we agree there is an issue. question is what does the draft say until the issue is resolved

<josb> using IRI would be playing safe (wrt. public perception)

<DaveReynolds> -1 to Harold

<csma> Josb, using URI would be playing safe (wrt technical implementation), as I understand

harold: starting with uris is safer because it is easier to express uri as iri, than iri as uri

<josb> any IRI can be encoded as a URI

<DaveReynolds> http://lists.w3.org/Archives/Public/public-rif-wg/2007Mar/0133.html

csma: we need reference to dave's text

<ChrisW> I propose: Symbols of this sort have the form "XYZ"^^rif:uri, where XYZ is a URI as specified in RFC 3986 (or an IRI as specified in RFC 3987)

chris: i put some proposed text in the irc
... I think everyone is saying we will have uris, and we should also include iris

sandro: i think rdf uses iri, but doesn't call them that

chris: rdf in spec, doesn't use iri - it defines a mapping

sandro: that encoding is the same as iri
... is there a normalization step?

csma: chris, in your wording, what is the semantic of the "or"

chris: yes, we will still raise an issue

<sandro> +1 Chris's wording

PROPOSED: remove from WD1 the sentence about open issue, add dave's proposed text from link above
... but replace one sentence with chris' text, and close the issue

chris: let's see the changes and then close the issue next week

dave: in what sense close the issue?
... so it gets replace with another issue about the syntax of rif:uri (iri or uri)

csma; next tech design topic: issue-31

<Francois> +q

csma: disjoint names for predicate symbols, function symbols and individuals

francois: I think we should not require them to be disjoint
... 1. practical applications
... 2. theoretical logic: it is tradition, but no real reason for having them disjoint
... 3. easier for parsers and humans

csma: what would drawback be?

<sandro> The antonym to disjoint-symbols is ....? overloaded symbols?

<Francois> +q

chris: if they are not disjoint, many implemented systems assume they are disjoint
... so will need to make a complicated encoding

and round-tripping will be more difficult

csma: RT more difficult because systems that required disjoint
... would create new symbols

jos: biggest argument for having them disjoint is extensibility of the core

chris: it's about translation/encoding
... every rule system can express things that cannot be expressed in core
... but in this case, it would be something in the core that would be complicated to express on a lot of languages

csma: but if rif requires disjoint sets than a system that requires symbols that are not disjoint will have to make them disjoint for rif core

<Harold> When we map both <Rel>s</Rel> and <Fun>s</Fun> to <Const>s</Const>, then we cannot uniquely invert that mapping.

francois: want to answer to what chris said. it's a good point that RT is a problem
... but we already have this problem anyway
... because of all the syntactic requirements

<csma> +1 to Francois

<josb> you cannot just rename URIs in exchange

<Harold> However, sorts such as something like <Const sort="relational/...">s</Const> and <Const sort="functional/...">s</Const> can keep the inverse mapping to <Rel>s</Rel> and <Fun>s</Fun> unique.

francois: ...don't put syntactic restrictions you don't need

<Hassan> I agree 100% with Francois! Local variables/symbols should be allowed.

csma: I think francois makes a good point

chris: no, I think it's different

<sandro> I think there are two conflated issues here. (1) Can you tell by the syntax of an identifier what kind of thing it is, and (2) Can you use the same string to name a predicate and a function at the same time?

chris: this is a semantic issue, not a syntactic one

<Francois> +q

chris: (ex: rules that quantify over predicates) need different encoding, rather than just renaming symbols

csma: question is whether we allow non-disjoint in core and dialects retrict to disjoint
... or whether we want core to be disjoint and dialects restrict to non-disjoint

harold: I put an example in the IRC
... within the const element there is an atrribute "sort" where we can disambiguate

francois: want to answer chris' point

chris: I said renaming symbols is a syntactic issue
... say you have rule that quatifies over predicates, and want to translate that through RIF

francois: we have a misunderstanding
... the position in the formula tells you what is the type of the symbol

<Hassan> Are you guys aware of something called the (typed) lambda-calculus? :-) It was invented by somebody called Alonzo Church for precisely what we are talking about.

<Harold> The language must support working with properties of properties and properties of rules. This can be done while staying first-order by having intensional semantics for predicates, where what seem to be second-order properties are really first-order properties of something in the domain of discourse which has the same name (URI) as the subject property. (This is what Pat Hayes calls "punning" and is widely implemented, although it is not normally a part of FOL

francois: you (chris ) are speaking of relation constants not relation variables

jos: a problem is that if you assert that 2 uris are equal, then they are equal only if they occur in a certain context

chris: is there a solution?

jos: hilog provides a solution, but not acceptable for pure fol dialect

<Hassan> Higher-order logic has solved all these issues a long time ago. Are we reinventing the (square) wheel again? :-(

chris: if jos is right about what francois is saying, then I agree that it is a simple renaming issue
... but now what uri refers to must be interpreted contextually

<josb> yes

mk: i don't understand what we are discussing: I think there are 2 issues

1. extensibility....we are talking about pure fol dialect, so if we don't introduce sort system, then fol dialect will not be allowed

2. round-tripping: it will not be possible if we do not separate the symbols

<josb> but then the URIs are lost!

csma: but the separation can be done at the translation step

mk: I'm not sure that will really work.

csma: there is still an issue about round-tripping, we still haven't

specified exactly what we expect: will it be identical or equivalent?

mk: I think jos's point is that it will be be a real web language

jos: RT: if names of symbols (which are uris) are lost, then you
... might lose some important information, and this might not be acceptable

mk: symbols have meaning outside of the system, so changing them might not be accepta ble

jos: could be a problem either way: (disjoint in rif, not in dialect) (not disjoint in rif, disjoint in dialect)
... which one do we want to cater to?

sandro: is this the same issue as the difference between owl 1.0 and 1.1

chris: I think it's different
... owl doesn't translate
... here the problem occurs during translation

csma: I propose we keep the issue-31 open for now

chris: mk, did you want them disjoing or not disjoint?

mk: I do not have a preference
... if non dis in core, then language that do distinguish will have problems with translation from RIF

csma: any rule lang will have to have a way to check whether a specific rule set can be translated
... and this will be one of those checks

chris: csma, is this a problem for production rules?
... (to have non-disjoint sets)

csma: I don't think it has an impact on production rules

chris: so functions, predicates, and individuals can have the same names?

hassan: yes, java allows you do to this.

sandro: which is restricted form?

chris: having them disjoint is restricted form

<Francois> +1 for Hassan's remark!

sandro: can something be both a property and a function?

<josb> as soon as you have equality, it is no longer trivial from a logical point of view

sandro: or can it only be one, and you have to disambiguate? disambiguation is too inconvenient

<Harold> Couldn't we optionally do static analysis including automatic contextual disambiguation of <Const>s</Const> into <Const sort="relational/...">s</Const> vs. <Const sort="functional/...">s</Const>, changing a ruleset in this way throughout, and then translate that to systems with disjoint <Rel>s</Rel> and <Fun>s</Fun>?

sandro: context for equality is always individuals, but users may have a hard time keeping track of that

harold: maybe we need more attention to static analysis of our rif rule sets

csma: disambiguation comes from sort mechanisms

harold: put it in validator and translator so that user does not have to be aware of it

csma: can someone summarize the positions we have discussed?
... who would like to do this?
... chris, can you summarize this discussion about disjointness - in an email?

chris: I can start

sandro: how about doing it on a wiki page?

harold: I think we should not edit other people's entries

sandro: (unless you're sure it won't offend the author)

csma: we will not discuss issue-25 today

UCR

csma: quick look at RIF-RAF actions

RIFRAF

action-175 complete

csma: axel had action, but he is not here
... we still need section 5 from Leora
... any other business?

<Harold> Thought on 'Etiquette Rules' for Sandro's "Pros and Cons Wikis" (action on Chris): Don't start new row without need, rather align your entry your pros and cons into 'the other column' of existing rows.

<PaulaP> +1

<Francois> quit.

<Hassan> +1

<PaulaP> bye

csma: propse to adjourn?
... look at your actions

<Hassan> #quit

- DRAFT -

RIF Telecon 10 Apr 07

10 Apr 2007

Attendees

Contents

Admin

Liason

Core

UCR

RIFRAF

Summary of Action Items

Scribe.perl diagnostic output