RIF Telecon 22 May 07 -- 22 May 2007

<ChrisW> Scribe: Adrian Giurca

<ChrisW> scribenick: agiurca

Core - Issue 30 (RDF)

Admin

csma: net meeting is next week same time same place

<ChrisW> action 288 complete

csma: approved the minutes from May 1 telecom

<ChrisW> RESOLVED: approve May 1 telecon minutes

<ChrisW> RESOLVED: approve May 15 telecon minutes

<ChrisW> action 286 continued

josb: I need F2F planning times

<josb> OK

csma: 10.30, 12.30 15.30 lunch times

<ChrisW> ack ??p43

<ChrisW> email of chairs: team-rif-chairs@w3.org

F2F

Liason

Technical Design - Issue 31

<ChrisW> action 289 complete

<josb> done

<ChrisW> action 287 complete

<josb> continued (sorry)

<ChrisW> action 285 continued

<csma> PROPOSED: RIF Core follows OS ("overlapping sorts") as on http://www.w3.org/2005/rules/wg/wiki/Issue-31 (resolving issue-31)

<Harold> I think we dont even need to talk about reflection here.

josb: we cannot write rules about the syntax in the RIF Core. We keep the resolution as it is and keep the issue on the reflection

<Harold> (BTW, *encoding* can be used for the syntax reflection Chris just mentioned.)

<ChrisW> ^josb^ChrisW

<ChrisW> RESOLVED: RIF Core follows OS ("overlapping sorts") as on http://www.w3.org/2005/rules/wg/wiki/Issue-31 (resolving issue-31)

<ChrisW> ACTION: Deborah to close issue-31 [recorded in http://www.w3.org/2007/05/22-rif-minutes.html#action01]

<rifbot> Created ACTION-290 - Close issue-31 [on Deborah Nichols - due 2007-05-29].

Technical Design - Builtins

<sandro> Deborah_Nichols, in closing the issue, please link to Jos's recent e-mail, since it helps explain how we closed it.

<AxelPolleres> SPARQL uses them directly, right?

MichaelKifer: We have to consider primitive datatypes. For example IRI or string. We need builtins to those datatypes.

csma: OWL datatypes are XML Schema datatypes

MichaelKifer: Add more builtins on strings and others. Is a good start to use XPath functions

<AxelPolleres> Michael, can you exemplify in a mail maybe some missing ones?

sandro: I agree with Michael. The functions and operators from XPath2 are not exactly what we want

<AxelPolleres> +1 to micheal and sandro. Extend where necessary only

agiurca: XPath2 is W3C recommendation. We may extend it if necesary.

<DaveReynolds> +1 to Sandro, replacing/modifying fno should be avoided - subset and RIF-specific extensions seems ok

<ChrisW> P38 who are you?

<AxelPolleres> for example, what seems to be missing is converting a string to a IRI, I think...

<DaveReynolds> Axel: conversions are included in fno

<ChrisW> Axel, are you on the phone?

<AxelPolleres> P38 might be me...

<Harold> We also discussed the correspondence between relational-builtin(Res, Arg1, Arg2) and Res = functional-builtin(Arg1, Arg2). I lean towards functional builtins. Dave Reynolds mentioned last week that the precise semantics of how to do things like type conversions may differ, xpath-functions is pretty specific on all that.

<AxelPolleres> I dropped out for bad connection in between.

MichaelKifer: We need manipulation of URL. We need to keep in mind that XPath is a functional language while we need a relational one

csma: May be SWRL builtins are not enough

<Harold> Chris, yes with functional builtins you can query salary(John +(170000,120000)).

<Harold> Equivalent to query salary(John 290000).

<AxelPolleres> Dave: I cannot find anything to convert a sting to a uri...

agiurca: I guess we need to allow both XPath2 and SWRL builins (and some other more?)

<DaveReynolds> Axel: doesn't http://www.w3.org/TR/xpath-functions/#constructor-functions-for-xsd-types cover much of that?

<Harold> Yes, Sandro, we have to look into possible mode declarations, builtins must be functional-builtin(In, In).

<Harold> 'In' means 'Input/Ground only'.

<IgorMozetic> I agree with Harold and Sandro (use functional instead of relational notation)

<GaryHallmark> var1 = add(var2,var3) : maybe add, maybe subtract, maybe "infinite answers", depending what variables are bound, no?

<Harold> Gary, yes, but (as I mentioned) var2,var3 arguments should be prohibited for builtins.

<Harold> (Free) vars are called 'Out' in mode declarations.

<AxelPolleres> Dave: if it is extensible with our own types, probably, but we agreed that rif:uri (or rif:iri) is not the same as xs:anyURI, or no?

<DaveReynolds> http://www.w3.org/TR/rdf-sparql-query/#SparqlOps

<Harold> Your example of 'invertible arithmetics' can be simulated, however, on a higher (term) level by representing numbers successor expressions or lists.

<GaryHallmark> harold, can you tell if a variable is bound or free using (only) static analysis?

<Harold> No, so there will be runtime errors for ill-written programs.

<ChrisW> Sandro: The RDF data model is a subset of the RIF data model

<Harold> Gary, Prolog provides extralogical primitives called var and nonvar (which could catch runtime errors, converting them to finite failures), but I guess we should avoid them in RIF.

<AllenGinsberg> should different RIF dialects have different builtins?

DaveReynolds: We need XPath to manipulate RDF data model

<AxelPolleres> Harold: how does "bound" from SPARQL fit in here? would you also consider that extralogical then?

csma: Would be possible to have the primitives for XML navigation in the abstract syntax?

<Harold> Axel, I didnt check but sounds as if "bound" corresponds directly to "nonvar".

<Harold> Axel, do u think we should align with SPARQL builtins wherever possible?

<ChrisW> harold, what is "nonvar"?

I guess in Prolog they are "free" and "bound"

<AxelPolleres> I have another question on built-ins: Do we also consider external calls which take e.g. the whole extension of a predicate into account? There are rules languages which allow this. (sorry cannot speak, since my connection is very bad)

csma: Not clear Dave issue about builtins for RDF data model

<Harold> Chris, e.g. in SICStus Prolog: http://www.sics.se/sicstus/docs/4.0.0/html/sicstus/mpg_002dref_002dnonvar.html

<AxelPolleres> bound is something different... it is very specific. Not sure whether we need it. It can be "circumvented".

<GaryHallmark> +1 for Sandro's strawman

csma: most of these operators are not really in rule languages

sandro: but they may be in other languages

<ChrisW> i don't think sparql:bound == sicstus:nonvar (nor !nonvar)

MichaelKifer: We need a number of string manipulation such as pattern matching

<GaryHallmark> do we imagine a dialect wherein one may define new builtins?

<GaryHallmark> if so, then we just need a "good enough" starter set for Core

<AllenGinsberg> gary: that's what I was trying to get at before

csma: we may have application specific predicates/functions. We want builtins covered by all languages

<ChrisW> +1 to "good enougH" starter set

<ChrisW> I thought the main question was whether to reuse an existing set

Xpath 2 has an extension point using the "op" namespace which is not bounded.

<Harold> Gary, I think Yes, we could have "dialect libraries" for new builtins pointed to by IRIs.

AxelPolleres: We want a general mechanism for builtins. For example there are builtins for extracting extension of a predicate

csma: probably that builtin should not be in the Core

<AllenGinsberg> we should be limiting the core to the "minimal" set of builtins

AxelPolleres: May be this can be done in an extension of builtins

<GaryHallmark> +1: should be possible to extend builtins to cover aggregation

<GaryHallmark> Michael wants accessor functions

agiurca: http://www.w3.org/TR/xpath-functions/#component-extraction-functions

<AxelPolleres> just for the records: A more general external predicate mechanism like I was talking about is e.g.

<AxelPolleres> [EIST05e]

csma: dialects could define new builtins

<AxelPolleres> www.kr.tuwien.ac.at/staff/roman/papers/ijcai05_final.ps

<josb> sure, dialects can define built-ins

<Harold> Axel, remember we had an 'external call' feature in RIF Core.

csma: I was proposed one specific limitation: I propose to use just functional built-ins

MichaelKifer: Other builtins like comparison operators cannot be represented as functions

<josb> we could have shortcuts in a surface syntax

<GaryHallmark> I think the names imply some type conversion will be done

<DaveReynolds> They are URIs not short form names

MichaelKifer: some of them for example refers to xs:duration and not to xs:dateTime

<Harold> Michael, I agree things like fn:seconds-from-time(17:30;12^time) look too redundant.

MichaelKifer: More special operators can be used

agiurca: I guess we need to use XPath2 as it is and possibily add more

josb: We could define a minutes function etc but using that ones from XQuery

<Harold> We could define mysec(?T) = fn:seconds-from-time(?T).

agiurca: Why we need to rename?

<IgorMozetic> +1 for josb suggestion

<sandro> PROPOSED: RIF Core will include a subset of F&O, used as functions (or predicates if they are boolean functions), in an "evaluation" style (with no unbound variables are arguments). We may also add some of our own (which might be aliases for F&O terms)

Harold: we could have short names

<GaryHallmark> I think the first task is to incorporate xpath builtins by reference to keep our spec shorter

+1 GaryHallmark

<csma> +1 to gary

<Harold> Why not: RIF Core will access a subset of F&O as an external library ...

<sandro> PROPOSED: RIF Core will include a subset of F&O, used as functions (or predicates if they are boolean functions, like comparators), in an "evaluation" style (with no unbound variables as arguments). We may also add some of our own (which might be aliases for F&O terms).

csma: Why they should be an external library?

<sandro> +1 Harold's "external library" view.

<IgorMozetic> +1 for Harold

<DaveReynolds> What does "external llibrary" actually mean?

Harold: In this way we keep our names. If the library changes then we keep our names

<ChrisW> I also don't understand the discussion

<ChrisW> what is an external library?

<GaryHallmark> I would like to omit Duration and keep Date, Time, Datetime

<GaryHallmark> in the F&O doc, these are all wound together

<DaveReynolds> +1 to Gary, we already agreed to omit xsd:duration and so would omit associated F&O functions

<sandro> Sandro: It may be that, rather than enumerating the functions we want to import, we can say "import all which operate on the datatypes we use"/

<Harold> The restriction could be determined by the input and output datatypes of entries in the F&O library: If we support both input and output datatypes, then we should permit the F&O entry.

<DaveReynolds> +1 to csma, clearer to implementors to list the specific functions

<sandro> csma: I worry about the burden that unbound list would put on implementors

<GaryHallmark> I think we have to "freeze" the version of F&O doc we reference

josb: We have to be carrefully for each external function we use. The signature etc

<francois> Sorry, I must leave now. bye.

<francois> bye.

<sandro> josb: We have to be precise in listing exactly which functions we support.

josb: I am in favor to precise functions we use in RIF

JeffP: Look at XML Schema Datatypes. We have to define the minimum datatypes supported. Other are optional. Second rule we need to be compatible with OWL and RDF

<Harold> If we remember our 'external call' feature in an earlier RIF Core version, then another question is: should something like <call> be used to call (external) builtins in a uniform manner?

JeffP: If we support many built-ins then the implementation will be large

<sandro> PROPOSED: RIF Core will require implementations to supported an enumerated subset of F&O, used as functions (or predicates if they are boolean functions, like comparators), in an "evaluation" style (with no unbound variables as arguments).

<sandro> RESOLVED: RIF Core will require implementations to supported an enumerated subset of F&O, used as functions (or predicates if they are boolean functions, like comparators), in an "evaluation" style (with no unbound variables as arguments).

csma: We need now to build this enumeratioon

<sandro> sandro: I suggest a wiki page, in RIF Core, where people can propose particular functions and operators that they think should be in RIF Core.

<Harold> One restriction could be determined by the input and output datatypes of entries in the F&O library: If we support both input and output datatypes, then we should permit the F&O entry.

<sandro> sandro: ... and which can be update with the current status.

<PaulaP> yes

<GaryHallmark> I assume builtins have an arrow sort?

<ChrisW> ACTION: Paula to create a wiki page in RIF Core to list builtins we import from F&O [recorded in http://www.w3.org/2007/05/22-rif-minutes.html#action02]

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

csma: PaulaP to create the wiki page for builtins

<sandro> ACTION: PaulaP to create a wiki page in RIF Core to list proposed & accepted builtins from F&O, and start by listing the ones she wants. [recorded in http://www.w3.org/2007/05/22-rif-minutes.html#action03]

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

<ChrisW> ACTION: Patra to create a wiki page in RIF Core to list builtins we import from F&O [recorded in http://www.w3.org/2007/05/22-rif-minutes.html#action04]

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

<ChrisW> ACTION: Rifbot to get a clue [recorded in http://www.w3.org/2007/05/22-rif-minutes.html#action05]

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

agiurca: I guess XML syntax discussion is better to postpone for the next telecon

<sandro> (Done via the Web Site. http://www.w3.org/2005/rules/wg/track/actions/291

AOB

Technical Design - XML Syntax

GaryHallmark: I built a schema derived from Harold DTD

<PaulaP> +1

<JeffP> y

- DRAFT -

RIF Telecon 22 May 07

22 May 2007

Attendees

Contents