Admin

csma: The next telecon will be next Tuesday, April 17

PROPOSED: approve minutes from March 27 telecon... (no objections)

RESOLUTION: approved minutes from March 27 telecon

csma: any proposed amendments to the agenda? (none)

Liason

csma: action review

action-268 complete

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

Core (technical design)

csma: Action review:

action-271 complete

action-272 continued

csma: The first item of technical design is issue-30 (rif:uri). There has been a lot of email disucssion about this; has it led to any agreement?
... Michael Kifier is not here yet
... Jos, can you summarize for us?

josb: I talked with Michael Kifer offline and I no longer have any disagreement. I thought the RIF Core Design document was a proposal for a dialect, but it is basically a framework so it is OK to be more general.

csma: But the issue is about what is the definition of rif:uri

josb: It is a sort, an IRI written in normal form
... no additional semantic commitments
... dialects may introduce additional restrictions

csma: Dave Reynolds, would you like to add any comments?

DaveReynolds: There was discussion about whether they should be IRI's or URI's.
... I wasn't sure about ?

josb: Dave, that would be specified in particular dialects.

csma: Jos, do you consider this issue basically resolved? Who should write the additional text to which everyone will agree?

josb: I'm not sure that we need additional text

csma: The issue is a question regarding what is the definition of rif:uri
... so we need a written definition to replace the pointer to the open issue that is now in the RIF core Design (WD1)

csma: Michael, who should write the text that will allow us to close issue-30? WD1 currently refers to this open issue.

MichaelK: What is the problem with the current text?

josb: It refers to an open issue

MichaelK: There was a question about syntax. Can we just say it is as specified in the relevant RFC (for URI or IRI)?

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

<ChrisW> RFC 3987 is the IRI RFC

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

csma: Is it OK to not have any agreed upon definition of rif:uri?

MichaelK: There is a definition, but we are not sure that it's what we will want in the end

DaveReynolds: On the question of syntax, I did propose a phrasing

MichaelK: I think you proposed to allow relative URIs as per RFC3986
... but relative URIs are just a shorthand

DaveReynolds: I also covered normalization, and changing URI to IRI

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

csma: So, the proposed resolution of issue-30 is that we remove the reference to the open issue-30 from the RIF Core Design, and include Dave R's suggested text? (see above link)

<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

<Harold> Earlier: <Ind iri="http://www.w3.org"/>

<Harold> Now: <Const iri="http://www.w3.org"/>

Harold: As I mentioned in my IRC posts above, we already had a syntax for IRIs in an earlier version of the RIF Core Design...do people remember? It was an attribute.

josb: In the RDF spec, it was not sufficient to just reference the RFC, so maybe it is not sufficient in our case either

csma: You are talking about syntax

DaveReynolds: The reason the RDF spec did that is that the IRI spec was not finished at that time
...so the RDF spec just included the text expected to be in the IRI spec.
... The difference between RDF's write up and the published IRI spec ended up being in just in the treatment of spaces

<ChrisW> 3987=IRI

DaveReynolds: The SPARQL spec was fine with just pointing to RFC3987 (IRI), which was published by then

MichaelK: Will we call them URIs or IRIs? Have we decided on IRIs?

Harold: JosB, DaveR, and some others prefer IRI's, and I am fine with moving there long-term. However, I think it would not hurt if we start with the URI subset of IRI's for RIF knowledge representation; full IRI's can still be encoded as URI's.

csma: Is there any objection to using IRI?

<josb> RDF, SPARQL use IRIs

ChrisW: I don't understand the consequences of the decision to use IRIs. I understand the reasons, and they are good, but I don't know of anyone who actually uses IRIs so have not heard of any experiences.

sandro: I'm concerned about the market perception. Most people still refer to them as URI (even if they are talking about IRI)

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

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

sandro: URIs and IRIs are mappable to each other, so in that sense they are equivalent

csma: I agree with Chris: I would rather be more conservative and use URI for now, and raise an issue about whether to use URI or IRI

MichaelK: But Dave R's formulation (suggested text) refers to IRI

DaveReynolds: People do use IRIs in RDF data. So, if we seem to communicate that RIF doesn't support IRI, it will surprise people

MichaelK: Dave R, in RDF, do people use URI or IRI?

ChrisW: How about if the text says "IRI or URI"? (the name of the sort can still be "rif: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?)?

MichaelK: How about we use URI now, and say that in future RIF might change to IRI?

csma: There is still an issue

sandro: I agree with Dave that the semantic web community will expect IRIs
... people are used to IRIs, they just refer to them as URIs
... we agree there is still an issue. The question is, what should the draft say until the issue is resolved?

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

<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 (so if we need to change our decision later, it will be easier to change from URI->IRI than IRI->URI)

<DaveReynolds:> -1 to Harold's remark that URI is the safe choice (IRI is the safe choice since it is the super set)

<josb> any IRI can be encoded as a URI

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

csma: Above, again, is the reference to Dave R's suggested phrasing

<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)

ChrisW: I suggest the above text. I think everyone agrees that we will have URIs, and that we should also include IRIs

sandro: I think RDF spec uses IRIs, but doesn't call them that

ChrisW: RDF spec doesn't use IRI - it defines a mapping

sandro: That encoding is the same as IRI ...
... is there a normalization step?

ChrisW: No, you are wrong

csma: Chris, in your IRC entry above, what does "or" mean?

ChrisW: We will still raise an issue. This is text to put in the RIF Core Design document in the meantime

<sandro> +1 Chris's wording

csma: PROPOSED: remove the sentence about open issue-30 from the RIF Core Design WD, and add
...Dave R's proposed text (see link above) but replace one sentence of that text with Chris's text from IRC,
... and then close the issue.

ChrisW: Let's make the changes, and review, and then then close the issue next week

DaveReynolds: In what sense close the issue?
... it will be replaced with another issue about the syntax of rif:uri (IRI or URI)?

csma; Yes, we need to open a new issue

csma; The next technical design topic is issue-31: should the names for predicate symbols, function symbols and individuals come from disjoint sets

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 the drawback be, to not having them disjoint?

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

ChrisW: Many implemented systems assume they are disjoint, so if they are not then translators will
...need to make a complicated encoding, and round-tripping will be more difficult

csma: You say round-tripping will be more difficult because systems that require these symbols to be disjoint will have to create new symbols, and then when translated back, they will not
... match the original?

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

ChrisW: It's about translation/encoding. Every rule system can express things that cannot be expressed in the core, but in this case, there would be something in the core that would be quite complicated to express in many languages

csma: But if RIF requires disjoint sets, then a system that requires symbols to not be 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.

<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.

Harold: I put an example in the IRC post above. Within the const element there is an atrribute "sort," which we can use to disambiguate

Francois: Chris made a good point that round-tripping would be 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

Francois: ...don't put syntactic restrictions that you don't need

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

csma: I think Francois makes a good point

ChrisW: No, I think it's different. This is a semantic issue, not a syntactic one
...you need a different encoding, rather than just renaming symbols
...(example: rules that quantify over predicates and you want to translate these rules through RIF)

<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?

csma: The question is whether we allow non-disjoint in core and let dialects restrict to disjoint
... or whether we make the core disjoint and let dialects restrict to non-disjoint

Francois: I want to comment on the point Chris made

ChrisW: I said renaming symbols is a syntactic issue

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> Interestingly a preliminary (now obsolete) version of the RIF charter said: >>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.) http://www.w3.org/2005/07/rules/charter.html#introspection

Francois: Chris, you are speaking of relation constants not relation variables

josb: A problem is that if you assert that two URIs are equal, then they are equal only if they occur in a certain context

ChrisW: Is there a solution to this?

josb: HiLog provides a solution, but it is not acceptable for the pure FOL case

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

ChrisW: If Jos is right about what Francois is saying, then I agree that it is a simple renaming issue
... but now what a URI refers to must be interpreted contextually?

<josb> yes

MichaelK: I don't understand what we are discussing: I think there are 2 issues:
...1. extensibility: we are assuming there will be a pure FOL dialect. If we don't introduce a sort system, then FOL dialect will not be possible
...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

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

csma: Regarding round-tripping itself, there is still an issue. We still haven't specified exactly what we expect, i.e, must it be identical or equivalent?

MichaelK: I think Jos's point is that it will not be be a real web language

josb: During round-tripping if the names of symbols (which are URIs) are lost, then you might lose some important information, and that might not be acceptable

MichaelK: What Jos is saying is that when symbols have a meaning outside of the system, changing them might not be acceptable

josb: We could have a problem either way (disjoint in rif, not disjoint in dialect) or (not disjoint in rif, disjoint in dialect)
... which types of dialects would we rather cater to?

sandro: Is this the same issue as the difference between OWL 1.0 and 1.1?

ChrisW: I think it's different. OWL doesn't translate. Here, the problem occurs during translation

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

ChrisW: Michael K, were you arguing to have the symbols disjoint or not disjoint?

MichaelK: I don't have a preference
... if non disjoint in core, then languages that do require the symbols names to come from disjoint sets will have problems with translation from RIF

csma: Any rule language will have to have a way to check whether a specific rule set can be translated; and this will be one of those checks

ChrisW: Christian, is this (having non-disjoint sets) a problem for production rules?

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

ChrisW: So functions, predicates, and individuals can have the same names?

Hassan: Yes, java allows you to do this.

sandro: Which is the "restricted form"?

ChrisW: Having them disjoint is the restricted form

<Francois> +1 for Hassan's remark!

sandro: Can something be both a property and a function? Or is it the case that it can only be one, and you have to disambiguate to find out which?
...disambiguation is too inconvenient

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

<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: The 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. See my IRC entry above.

csma: Disambiguation comes from sort mechanisms

Harold: We could put the disambiguation in validator and translator software, so that the user does not have to be aware of it

csma: Can someone summarize the positions we've discussed (pros and cons) regarding disjointedness of individuals, predicates and functions in the RIF core?
... Chris, can you do this, in an email?

ChrisW: I can summarize the points from today's discussion (but I may not be able to keep up with the ensuing flood of email).

sandro: How about doing it on a wiki page?

ChrisW: ok

Harold: I think we should follow a rule of etiquitte for this wiki whereby we do not edit other people's entries

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

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

csma: We will not discuss issue-25 today

csma: We will now skip to the RIFRAF agenda item

RIFRAF

csma: RIFRAF action review:

csma: Leora has action-173 to revise and ontologize section 5 of RIFRAF...she is not here to report

csma: Axel has action-265 to complete his RIFRAF exercise...he is not here to report

action-175 complete

AOB

csma: Any other business? ... (none)

csma: People, look at your actions for next week. I propose to adjourn now.

<PaulaP> +1

<Hassan> +1

<PaulaP> bye