RIF F2F13 -- 15 Apr 2009

<ChrisW> Meeting: RIF F2f13 15-Apr-09

<sandro> scribe: harold

Swap April 15/16 Agenda items: Tonight XML Schemas, Tomorrow Issue-93

On April 17 we have to finish at 4PM.

<csma> http://www.w3.org/2009/04/07-rif-minutes.html

<csma> PROPOSED: Close ISSUE-86 and ISSUE-87, addressed by the current text of http://www.w3.org/2007/OWL/wiki/InternationalizedStringSpec

<josb> +1

<sandro> +1

<josb> The text: Despite the semantic equivalence between typed rdf:text literals and plain literals, the presence of typed rdf:text literals in an RDF graph might cause interoperability problems between RDF tools, as not all RDF tools will support rdf:text. Therefore, before exchanging an RDF graph with other RDF tools, an RDF tool that suports rdf:text MUST replace in the graph each typed...

<josb> ...rdf:text literal with the corresponding plain literal. The notion of graph exchange includes, but is not limited to, the process of serializing an RDF graph using any (normative or nonnormative) RDF syntax.

<DaveReynolds> +1

<josb> http://www.w3.org/2007/OWL/wiki/InternationalizedStringSpec#Relationship_with_Plain_Literals_and_xs:string

<ChrisW> +1

<AdrianP> +1

<AxelPolleres> +1

<csma> RESOLVED: Close ISSUE-86 and ISSUE-87, addressed by the current text of http://www.w3.org/2007/OWL/wiki/InternationalizedStringSpec

<ChrisW> ACTION: chris to close issue-86 issue-87 [recorded in http://www.w3.org/2009/04/15-rif-minutes.html#action01]

<trackbot> Created ACTION-732 - Close issue-86 issue-87 [on Christopher Welty - due 2009-04-22].

<DaveReynolds> Before or after SPARQL group review?

<csma> PROPOSED: publish rdf:text as a LC

<josb> +!

<josb> +1

<sandro> +1

<AxelPolleres> +1

<GaryHallmark> +1

<AdrianP> +1

<ChrisW> +1

<DaveReynolds> 0

<MichaelKifer> +1

<ChrisW> DaveR: Abstain - Would have preferred to get feedback from SparQL first

<csma> RESOLVED: publish rdf:text as a LC

<AxelPolleres> I understand that I can ask SPARQL WG to review next week already?

<sandro> AxelPolleres, you should probably wait until it's actually published, but... sure, whatever.

Jos: Could we put a possible change from XML Schema 1.0 to XML Schema 1.1 on the agenda?

Sandro: The only reason not to go to XML Schema 1.1 would be that they are in LC (since January).

Jos: Still better than referring to 'broken' one in XML Schema 1.0.
... Talking about XML Schema DATATYPES.

<sandro> PROPOSED: We'll use XML Schema Datatypes 1.1 (not XML Schema Datatyoes 1.0) in our specs.

<josb> +1

<sandro> Jos: It makes lots of things well defined that are not currently well defined.

<DaveReynolds> +1

<sandro> +1

Harold: What about the W3C XML Schema validator XSV? When will it be upgraded?

Sandro: Has been maintained by Henry Thompson.

Harold: XSV is also 'responsible' for validating Datatypes at the 'leaf' level of XML instance trees.

<ChrisW> ISSUE: Update all specs to reference XML Schema datatypes 1.1

<trackbot> Created ISSUE-98 - Update all specs to reference XML Schema datatypes 1.1 ; please complete additional details at http://www.w3.org/2005/rules/wg/track/issues/98/edit .

ISSUE-95 (List Datatype)

Axel: How are 'Seq lists' related to RDF lists?
... awkward to have 3 different kinds of lists.

Jos: Lists in RDF have no semantics.

http://www.w3.org/2005/rules/wiki/Lists#Semantics

Christian: Content of an XML list cannot be complex.

<AxelPolleres> If we doe the semantics purely in terms of pairs, then it would be closer to RDF lists.

Christian: Non-ground lists would not be allowed in PRD.

<AxelPolleres> ... Harold, you confirmed this (?)

I think, yes.

<josb> eeeeeh RDF lists dont have semantics, so how can our semantics be close to that?

Christian: What about Forall ?x IF p(Seq(a ?x c)) THEN ...

<AxelPolleres> jos, it would be nice to be able to - at least - convert between well-formed RDF lsits and RIF lists, that might be possible with a bunch of RIF rules... like constructing lists in Prolog.

<GaryHallmark> PRD should have no problem with vars in lists provided the rule is safe

Harold: Only difference is if the above ?x is universal (as above) or existential.

<sandro> PRD will not actually handle unbound variables stored in a list.

<sandro> cke: List contain concrete values

<GaryHallmark> ... begging the question, what are the safe binding patterns for List

Harold: Existential in queries.

Christian: What about Forall ?x IF Seq(a ?x c) = Seq(?y c b) THEN ...

Harold: ?y is existential here.

<Zakim> AxelPolleres, you wanted to ask about connection to rdf:List and accessor built-ins

<Zakim> DaveReynolds, you wanted to ask about Core and to

Dave: What does this mean for safeness?

Michael: We have to extend the safeness condition for lists.

Dave: Disguised function symbols in Core.

<josb> Dave, we would not allow variables in lists in the head

<josb> and perhaps also not in the body

<josb> (in Core)

Harold: Dave is saying you can encode functions using lists, eg the first element of a list could be the function symbol, the remaining ones its arguments.

Michael: Need to think more about it. Still, we could extend the safeness condition to lists.

Christian: How implemented in JRules etc.?

<DaveReynolds> It seems to me if you can't construct new lists they are pointless, if you can that you can have non-terminating generation of recursive datastructures. That would preclude datalog engines and the notion of strong safety. OK by me but seems like a big change.

Changhai: Yes, can be implemented, but would be rather advanced.

Michael: If we don't allow open lists in the head, and are always smaller than in the body, then it could be in Core.

Jos: Better: no lists in Core.

Axel/Sandro/Gary: Emulate lists with built-ins.

<sandro> sandro: This is just another builtin.

<sandro> sandro: (as far as Datalog/Core is concerned.)

Axel: Do we really need (these 'amputated') lists in Core?
... Cause we could have the distinguished function Pair symbol.

Changhai: What about disjunctions?
... Lists that mostly would be constant.

Christian: For all customers, if ?x is the bank account list and length of ?x is greater than 3 ....
... You still need some kind of list type.
... To check that there is this (finite) list of the customers' bank account.
... Would it be advisable to have some list processing operators in Core, and then have list terms in BLD and (slightly different) in Core?

Jos: Will lead to discrepancy with BLD.

Sandro: Data could come from RDF.
... List operators would be in Core.

Christian: You could write Forall ?x ?y IF ?x{Att->?y] AND func:length(?y) < 3
... without needing to completely define what the list ?y actually is.

Michael: Semantics would still be provided.

Christian/Sandro: Would not need to defined in Core, only in BLD and PRD.

Gary: May make sense.

Christian: In DTB.

Gary: You have to say it's a list, just as it could be an integer etc.
... (but not give details)

Sandro: Confused why you cannot construct lists in Core.

Jos: Christian proposes special lists in Core.

Michael: You can allow ground lists in Core.

Chris: Head and body?

Michael: Yes.

Gary: But it should be something useful.

Chris: No variables inside lists.

Christian: Forall ?x ?y IF Seq(a b c) = ?y would be allowed?

Michael: Yes.

Harold: OK, let's introduce Core ground lists plus their built-ins.

<DaveReynolds> Gary - we don't non-termination, that's the whole E-S strong safety!

<GaryHallmark> dave, is E-S harder to spec with lists than with e.g. numeric-add?

<DaveReynolds> Gary - the point is that E-S eliminates all useful constructions of lists.

Christiann: Forall ?x ?y IF Seq(a ?x c) = ?y AND ?x =b

<DaveReynolds> Gary - If you want useful list construction just have Jos' safety construction and drop the goal of allowing datalog engines.

Christiann: Groundability could be handled like the safeness condition.

Harold: 'Save groundability' notion could be introduced, even if 'conservative' (not catching all groundable cases): Better than only 'plain' ground lists.

<DaveReynolds> Could the list of options go in the minutes?

Christian: Three options on whiteboard: One is a short version of the above.

12 mins break now.

<GaryHallmark> I sense one problem is that I would like to see Core grow to the intersection of PRD/BLD and others would like to see it shrink to finite models only...

Christian's three options:

1) Ground lists + builtins in Core

<DaveReynolds> Gary - agreed. That was the whole debate over this E-S strong safety notion. I'd be happy to have a non-termination in Core and have usable lists.

<AxelPolleres> FYI: The reference to XML Schema DT 1.1 in rdf:text has been fixed

2) Safe lists (no unbound var inside lists) + builtins in Core

3) Same as 2) but PRD (no lists in Core)

Harold: Christian's option 2) corresponds to above 'safe groundability'.

<ChrisW> scribe: AdrianP

Issue-94 (Objects)

csma: sent slides

Harold: we discussed a year ago that OWL cardinality constraints can be used
... not defined in RIF, delegate to OWL, for instance

csma: in PRD the is action modify which has semantics of assert with replacement semantics

<sandro> csma: action MODIFY is like assert, but with replacement semantics.

csma: modify = replace all the values and assert new ones

<sandro> new ONE

cke: object model can be changed in option 4

csma: interchange object model can be outside of RIF, e.g. in UML or XML Schema

Gary: frames are general; need to be mapped into a concrete data model;
... do some analysis and figure out the implied data model
... declare the data types and constraints - then you don't need the complex analysis

Sandro: why not option 5

Gary: option 5 does not ensure interoperability

<sandro> csma: Option 5.5 -- have a standard metadata field for linking to an XML Schema

Gary: data model might not be XML schema

Chris: option 6 you would need to duplicate the data model in RIF

Michael: agree with Gary- if something is specified out of RIF but affects the semantics

Gary: like to have syntax where you know the semantics
... like to explicitly know how to translate it into the specific execution data model

Harold: multi-valued treated like a set
... replace the whole set with a new one
... single-valued is a special case
... like in F-Logic

Michael: in F-Logic you have types which indicate that

Sandro: seems to be reasonable that type information is additionally provided

<sandro> Gary: I'm not saying type infpormation should be mandatory, just that it should be possible to supply.

csma: why not using existing syntax for describing the data model?

Gary: should be specified in the language we are using, i.e. RIF

<sandro> Gary: I want to specified my RIF data model using RIF constructs.

csma: what about a mapping von XML Schema to RIF

Gary: cardinality constraints seem to be a very small extension of the RIF syntax
... we should provide this expressiveness in RIF

<Harold> PRD's Modify construct would just be a special case by replacing a singleton-set value; BLD could also be extended with a Modify construct, which would replace general set values.

cke: in XML schema we have all this kind of expersivness

Gary: but not solved in RIF

csma: impacts the semantics of rules or not?
... seems to me that it is external to RIF

<sandro> (It doesn't affect the entailments. It may affect type-errors and performance.)

<DaveReynolds> Surely it does affect entailments. If you say "slot s has cardinality 1" then a rule o[s->"a", s->"b"] would raise an error.

Gary: option 6 introduce singleton and set to distinguish

Sandro: may affect type checking, performance, ...

cke: option 6 example is this information part of the rule?

Gary: yes

Michael: how to define interoperability?

Gary: would be like type checking
... basically like a constraint
... this example is only for frames

<Harold> PRD: Given single-valued obj[slot->oldval], the statement Modify(obj, slot, newval) leads to obj[slot->newval].

<Harold> BLD: Given multi-valued obj[slot->oldval1] AND ... AND obj[slot->oldvalN], i.e. obj[slot->{oldval1, ..., oldvalN}], the statement Modify(obj,slot,newval) also leads to obj[slot->newval].

csma: will lead us to a new data model language
... all this already exists in othere languages

Chris: sounds like option 4

<Harold> My proposal is compatible with option 4.

<Harold> (Without need fro static analysis)

<Harold> Just add a modify operator that ALWAYS replaces ALL values.

<Harold> (ALWAYS: in PRD and all follow-up languages extending BLD)

csma: first two options mean add information explicitly
... three is use a new construct for different multiplicity

<Harold> When I wrote "BLD: Given multi-valued ..." I meant a future BLD extension allowing a Modify.

csma: 4 and 5 ignore
... 6 include some external description
... 5 include some external description
... 6 add syntax to RIF

Michael: out-of-band does not make sense from the point of interoperability

Chris: option 5 relies on other external mechanism

Sandro: Gary, would a new error type work for you?

Gary: PRD you can directly indicate errors

<GaryHallmark> example of constraint rules: http://lists.w3.org/Archives/Public/public-rif-wg/2009Mar/0135.html

Michael: thought the problem was, that Gary sees problems when you translate Core into PRD

Gary: for instance should be able to say that a person only have one birthday
... should be able to explicity say this in terms of a cardinality constraint

<AxelPolleres> isn't modify just delete all existing values and add the new value?

<sandro> chris: The issue is: Should we have Cardinality Constraints (and perhaps Type Constraints) in Core?

Gary: issue is with core; can I have an explicity cardinality constraint in core

<sandro> kifer: f-logic has it.

<AxelPolleres> Answer set programming has it as well.

Harold: f-logic and RuleML have special syntactic constructs to distinguish cardinality

Michael: SWRL has cardinality constraints

<sandro> mk: SWRL and Flora-2 have cardinality constraints.

<AxelPolleres> OWL implies equalities, doesn't have card constraints.

<sandro> jos: at-most-2 cardinality gives you disjunction. at-most-1 cardinality adds equality.

Harold: integrity constraints could be introduced and used to define cardinality constraints

<sandro> mk: Integrity Constraints require the Closed World Assumption.

<sandro> mk: equating two mothers is a problem....

Harold: integrity constrain semantics instead of open equality semantics could be introduced

Chris: needs a closed assumption

Harold: person who uses RIF's multiplicity="1" attribute makes a closed world assumption

Gary: my original proposal was to have the syntax but its just like a comment
... in BLD and PRD the semantics is then defined

<DaveReynolds> But different surely.

Chris: this is option 1

Michael: interoperability?
... would need to define what interoperabiltiy then means?

Chris: option 1 uses meta data, so it is meaningless / might be ignored

Michael: this ok, if we define interoperability accordingly

Chris: PRD doesn't ignore meta data?
... option 4 does not allow you to express cardinality constraints
... Gary wants them

Sandro: Gary wants type checking

<DaveReynolds> But Gary you are giving it different semantics in BLD and PRD so that isn't an argument for them in Core.

Michael: semantics of cardinality in Core is different from the semantics in PRD

<DaveReynolds> -1 for logical constraints in core, 0 for closed world integrity constraints (potentially useful, huge work, don't see how to get it done in remaining time)

<sandro> mk: It's a good idea, but I'm worried it will be musused.

<AxelPolleres> -1 (it seems that with a decent semantics for modify, there can still be a PRD (sub?)dialect based on Core without)

<AxelPolleres> (... i.e. modify meaning delete all existing values and assert new value)

<sandro> Chris: This would not be the first feature we abandoned.

<sandro> (first useful features)

<sandro> chris: It seems we're leaning toward option 4.

<AxelPolleres> dave, are you on the phone?

<DaveReynolds> Yes but I can't hear anything

- DRAFT -

RIF F2F13

15 Apr 2009

Attendees

Contents

ISSUE-95 (List Datatype)

Issue-94 (Objects)

Summary of Action Items

Scribe.perl diagnostic output