RIF F2F meeting 2 June 2007

2 Jun 2007


See also: IRC log


Mike_Dean, +43.512.507.aaaa, Hassan, Igor, Jos, Giorgos, DaveR, Gary, Axel, MichealS, Markus, Paula, Francois, Allen, JohnH, Harold, Sandro, Chris, Christian, AdrianG, MichealK, PaulV
Christian de Sainte-Marie
Franc, johnhall, Markus Krötzsch, PaulaP, AdrianGiurca, Michael Sintek


<ChrisW> Meetin: RIF F2F meeting 2 June 2007

<ChrisW> Chair: Chris Welty

<Harold> http://www.w3.org/2005/rules/wg/charter.html#xml-syntax

<Harold> "The primary normative syntax of the language must be an XML syntax. Users are expected to work with tools or rule languages which are transformed to and from this format."

<mdean> can someone dial-in to zakim?

<Harold> Mike, they try it now.

<mdean> thanx

Overivew of meeting agenda

<Harold> 3.2. Phase 2 Scope: http://www.w3.org/2005/rules/wg/charter.html#actions

<AllenG> testing 1 2 3

<Harold> Adrian G

<Harold> http://www.w3.org/2005/rules/wg/charter.html#horn

<Harold> "The Phase 1 rule semantics will be essentially Horn Logic, a well-studied sublanguage of First-Order Logic which is the basis of Logic Programming."

Abstract Syntax

<Harold> http://www.w3.org/2005/rules/wg/charter.html#xml-syntax

<Harold> "... In order to allow interoperability with RDF and object-oriented systems, the syntax must support named arguments (also called "role" or "slot" names), allowing n-ary facts, rules, and queries to be provided through property/value interfaces ...."

<sandro> sandro: omitted sort == universal sort? jos: yes

<Harold> EBNF syntax for sorts: "value"^^sortname

<Harold> http://www.w3.org/2005/rules/wg/wiki/Core/Positive_Conditions#sec-multisorted-logic

<Harold> Const: "123"^^xsd:long and Vars: ?v^^xsd:dateTime

<sandro> Francois: what is in logic is called "sort" is called in programming "types"

<sandro> Francois: and in this group we're using it with the meaning of "syntactic category"

<AxelPolleres> at some places still arrow_sort appears... search and replace should solve that.

<DaveReynolds> Harold: surely for vars one would want to separate type declaration from usage and not repeat the annotation at each usage

<Harold> Dave, right, the <declare> place in the <Forall> is the distinguished occurrence, where sorting should be done once.

<Harold> Francois, we had 'type', then the WG wanted to use 'sort': compatible with that notion in 'order-sorted logic'.

<Harold> Hassan, we have that: signature NAME s1 * ... * sn ? s , r1 * ... * rk ? r , ...

<Harold> Hassan, we have that: signature NAME s1 * ... * sn ->? s , r1 * ... * rk -> r , ...

<Harold> Hassan, we have that: signature NAME s1 * ... * sn -> s , r1 * ... * rk -> r , ...

<AllenG> CGI333-allen = AllenG = AllenGinsberg

<sandro> Who here has actually carefully read the text http://www.w3.org/2005/rules/wg/wiki/Core/Positive_Conditions#sec-multisorted-logic ?

<Harold> Francois, we have this: Forall x^^HumanBeing y^^TelephoneNumber (has(x y) :- wantToBeConnected(x y))

<AllenG> sandro: I reviewed the original version; don't know if it changed much since then

<Harold> Francois, we have this: Forall x^^HumanBeing y^^TelephoneNumber (has(x y) :- wantToBeConnected(x))

<Harold> Adrian, if your office phone is 1234, we have this: has(Adrian^^HumanBeing 1234^^TelephoneNumber)

<AllenG> Franc = Francois

<agiurca> I completely agree

<sandro> Does it make sense to say 7^^primeNumber ?

<agiurca> I guess we may have Sort (abstract) subclassed by Type, ASort and BSort . Then ?x^^Predicate is possible, where Predicate is an instance of BSort. Also is possible to have ?x^^Computer where Computer is associated with an ASort (a catresian product of Type instances)

<sandro> Scribe: Franc

Francois: we should nt confuse (1) syntactical categories, (2) sorts in the sense of programming types, and (3) casting i.e. conversion between values from different sorts (in the senser of programming language types).

Axel: I suggest a generalization of this.

<MarkusK> Axel: we could consider Boolean signatures as special arrow signatures with result type Boolean.

<GaryHallmark> axel: and primitive sorts are arrow signatures of 0-arity

Dave: we use the diagramas as abstract syntax. does not say what is declared.

<agiurca> +1 Gary

<Harold> Sandro, so far we did not have things like 7^^primeNumber on the 'top-level' of statements but only within Atoms/Uniterms like age(Mary^^HumanBeing 7^^primeNumber).

<Harold> However, in the recent slotted/frame extension, 7^^primeNumber would be ok *as* a statement.

Hassan: suggest on the bord to distinguish between: signatures as sets of symbols.

With a signature, one can ssociate sorts (one sort of each symbol). Sorts understood as arities.

Christian: Why is this different from signature in our document?

Hassan: it is not.

Axel: Can the notion of eg Boolean sorts and signature sort be unified in one notion?

Michael: Is the issue to get rid of the name 'sort'?

Axel: draws on the borad: Terms consist of symbols that are var or cons. We laso have uniterm. For each symbol we would have a signature.

<Harold> Michael, Francois and Mike, could we solve Francois' concern about (1) syntactical categories, (2) sorts by expressing (1) as name spaces and (2) local names, e.g. for (1) Ind vs. Data and for (2) HumanBeing vs. dateTime, as in.../rif/Ind#HumanBeing vs. .../Data/xsd#dateTime.

Michael: What is the issue?

hristian: Sorts appear everywhere in the doc but nowhere in the abstract syntax.

<GaryHallmark> csmatian: the issue is how to add sorts to the ASN

Dave: This diagram is a syntax no data model.

Adrian: terms are associated with signatures.

Axel: we have several signatures. Signature 0 is just the sorts.

<MarkusK> Axel: collapse different versions of signatures unless distinctions are essential

<sandro> In document: Const ::= CONSTNAME | '"'CONSTNAME'"''^^'SORTNAME

<sandro> Var ::= '?'VARNAME | '?'VARNAME'^^'SORTNAME

<sandro> from http://www.w3.org/2005/rules/wg/wiki/Core/Positive_Conditions

<MarkusK> Chris: confusion is arising from mixing up syntax and semantics/data model. Let us use EBNFs for clarity and only derive normative UML in the end.

Chris: writes down a BNF grammar and claims it expresses the same as the diagramme.

<sandro> csma: the sorts associated with var are ONLY in the declaration, not in the variable usage.

<agiurca> SORTNAME is a "REFERENCE" is not the sort itself. The name is a selfrefenece to the sort.

<MarkusK> Harold: in some formalisms, complex terms can be used as operators, hence they need signatures too.

<MarkusK> Harold: HiLOG is an example for this.

<MarkusK> csma: ok, but this needs to be restricted for RIF Core

<agiurca> IF RIF will have a vocabulary (for example RDFS) part then Const Var etc will "refer" the schema parts by ising references (in XML they can be URI)

<sandro> ScribeNick: AllenG

csma: pick up from last session

<Harold> Adrian, right we have the option of this kind of 'webizing'.

csma: only thing that needs a sort in syntax is var
... ... asssuming that there is a declaration section

<sandro> Chris: maybe the only thing that needs sorts are variables in the condition diagram, assuming sorts for consts are delcared some place.

<sandro> Jos: A symbol may have different sorts -- so it may be distinguish the different sorts in each use.

jos: symbol may have different sorts

<sandro> MichaelK: I think you mean signatures

chris: let's get on the same page NOW!
... we are talking about the syntax for conditions (a la diagram)

Harold: var's can have different sorts in same condition
... but they must be compatible

chris: might be getting confused about what a sort is: look in doc

<sandro> Michael: every constant has a sort.

michael: sorts are part of the language; you declare a const as a sort

chris: what sorts are there, other than primitives

michael: sorts can be user definable

chris: now I am confused

adrian: sort is a classifer for a const or var

csma: like a type in a prog lang?

adrian: could be

axel: use sorts to distinguish pred and fcn?

chris: not according to what I heard

axel: rules can assign sorts to things

michael: you can write rules that assign sorts

<Harold> Allowing 'multiple inheritance', in a condition, a Var occurrence x can eg be sorted as a Car and another occurrence x can eg be sorted as a Ship. If these are disjoint, the condition fails; if they have a non-empty intersection, eg AmphibiousVehicle, the sort of both x occurrences will be semantically specialized to that intersection.

michael: but different than classes

jos: to axel: sort can not be assigned to things
... whether we allow a sym to have different sorts or not?

michael: that is allowed
... now we are talking about declaring sorts: but that is not how it happens?

chris: we still don't know what you

mean by sort

<sandro> Hassan: we might be confusing Symbols and Symbol-Occurances. Each Symbol can have multiple sorts, but each occurance has one source.

hassan: this is a confusion of levevls: a symbol occurence has a single source
... a symbol can have more than one sort; an occurence just one

chris: what is the sort of f in f(a,b)

michael: signatures are different than sorts

chris: in the current syn everything is supposed to have a sort, right, and a signature.

<Harold> Hassan, again we have that overloading: signature NAME s1 * ... * sn -> s , r1 * ... * rk -> r , ...

michael: yes
... (at the board) f^^foobar (that is how it is currently written)
... e.g. f^^xsd:string

<sandro> Sandro: can you have "f"^^xsd:int ?

<sandro> MichaelK: No.

markus: please use concrete sorts, not "foobar". how relevant is possibility of definition of new sort?s

michael: probably don't allow user defined in core

<sandro> Michael: a symbol is really a pair like ("f", xsd:string)

<sandro> Michael: Java has sorts, like in 123 is an integer. A datatype

markus: don't perceive sorts as classes. sorts are like datatypes in a prog. lang.

csma: but I understood sorts as more general as datatypes.

<MarkusK> Markus: we should try to use concrete examples when talking about sorts, in order not to suggest using sorts in place of classes in knowledge representation.

csma: we declare types and sigs in another doc somewhere. when you use a var in a rule, you may declare its type
... const's type can always be retreived from its signature

<Harold> Markus, do you mean we should initially have only 'primitive sorts', not 'user-defined sorts'?

csma: some types are in-built, but some can be defined by user (by reference to an external doc)

michael: get bcak to f(a.b) example

<MarkusK> Re Harold. We should foresee user-defined sorts for extensions of RIF, but having a concrete list of primitiv sorts as a base is probably easier to understand

<sandro> MichaelK: Sort in RIF Core should not be extensible -- they should NOT be for modeling knowledge.

michael: sorts will be fixed for the core. dialects might allow user-defined

<MarkusK> +1 MichaelK

csma: remember we are talkng about language that exits

jos: we need sorts to distinguish to pred, const, vs. fcn symbols. sigs are not enough for that

<sandro> Jos: we need sorts to distinguish between function symbols, constant symbols, predicate symbols.

<MarkusK> +1 Jos

axel: we need sorts in rif core for "pred", etc

chris: now I am worried that you axel agree with jos.

<sandro> Chris: Most of our symbols will be of type URI -- whether they are predicate is another mechanism.

jos: we need sorts to fix the domain of interpretation

<Harold> Markus, I agree, 'user-defined sorts' could be in a (future) dialect. MichaelK (on the whiteboard) also agrees to this. Why not right away reuse RDFS and OWL subClassOf sort hierarchies?

michael: there is no disjointness in core (between pred, fcns, etc)

axel: what does a = b mean then?

michael: sigs will take care of that

<sandro> mdean, are you able to follow any of this?

<sandro> (or hear it, I mean.)

gary: what is f in f(a,b)?

<MarkusK> Re Harold: I do not think OWL classes are like sorts, I agree with Jos' view that sorts distinguish domains of interpretation (on a meta-semantic level).

<sandro> Gary: so in f(a,b) is f of sort "string" or "function symbol" ?

<mdean> yes - i can hear it fine

<mdean> thanks

<sandro> (We've had a couple loud airplanes overhead.)

<mdean> i was wondering what that was

chris: typical case , e.g., P(a,y) where, most commonly <"P", rif:uri>, <"a", rif:uri>, <"y", xsd:string>.

<sandro> Chris: P(a, ?y) => sorts <"p", rif:uri> ( <"a", rif:uri>, <"y", xsd:string> )

chris: since P is a pred it will have a signature like...

<sandro> Chris: P *also* has a signature: <"P", rif:uri> hasSignature rif:uri X xsd:string

michael: signature <"P", rif:uri> => rif:uri X xsd:string

<sandro> Chris: P also has an extension { .... } "what populates the predicate"

<sandro> (not in the syntax)

<Harold> The distinction of function vs. predicate ( the top-level syntactical categories) could be made with namespaces or within the pathnames of sort webizing: .../function/unary/Int2Int vs. ../predicate/unary/Int.

chris: for vars, not in the syntax, they have binding associated

dave: did you really mean <"P", rif:uri> => rif:uri X xsd:string ?

<sandro> DaveR: I expected the signature to be more like ( Person X TelephoneNumber ). The signature certainly shouldn't care about where the variable is.

chris: dave is saying this doesn't look like a sig of a pred.

michael: you can have several signatures....

<sandro> +1 DaveR

<Harold> Markus and Jos, these 'levels' could be combined as I indicated with the namespaces and pathnames above.

csma: rif:uri could be associate with type "human"

chris: not

<sandro> Chris: the signature of spouse is Person X Person

chris: take pred "spouse", sig would be person x person?

<sandro> MichaelK: No, that, would be too much.

michael: sig wil be rif:uri x rif:uri

<Harold> Chris, this could be indicated by ../predicate/binary/Spouse.

sandro: what about vars?

michael: <"x", xsd:string>
... which means it can only be bound to types of xsd:string

<scribe> new scribe : john hall

<sandro> MichaelK: what I mean by signature is much less than (Person X Person) stuff.

<MarkusK> Harold, I fear that combining the levels yields confusion ("What exactly is a sort"-question) and possibly offers incompatible ways for modelling the same knowledge (you can refer to RDFS/OWL classes in RIF conditions [by some interoperability mechanism yet to be clarified]). I think RDFS/OWL interop should not come in via sorts.

<Harold> Similarly, the function fatherOf could be sorted by .../function/unary/HumanToMale.

<sandro> Scribe: johnhall

csma: MK wouldtou retrict use of core only to the primitive sorts here?

<MarkusK> I would.

hassan: what are signatures for p(1,x) and p("1",y)

Michael: xsd:string the two examples woul be illegal

<sandro> Michael: With might have P with two signatures: string X string, int X int . Then P(1, ?X^^int) would be okay.

<sandro> Axel: I think we want an untyped variable to be okay for any spot.

chrisw: are some variables not restricted?

<Harold> Markus, we could *use* RDFS/OWL to define the sort lattice that we need, clearly announcing it as a reuse of the RDFS/OWL languages for our RIF content.

csma: what if O(int, int) but want to restrict ins to 1 100
... e.g. if O is age

michaale: not so restricted

<MarkusK> Harold, reusing RDF constructs on a language-level is always slightly problematic, since RDF is interpreted in a single model (the reused syntax parts cannot be seperated semantically from the object-level statements).

franc: in modeling langs, like to have datatypes, eg age 1 to 100
... in prog langs,considered harmful
... you will add ages

<MarkusK> (Harold) So your RDFS-statements would appear semantically as part of your modelled domain and semantically interact unintentionally.

franc: but will compute something that is not an age

<MarkusK> (Harold) It is known that this design of RDF easily creates an inconsistent logic.

franc: cannot have data tyoes with upper and lower bounds
... and RIF will be a prog lang

chrisw: get back on track
... DaveR are you clear on las q?

DaveR: only for simple case

<sandro> Francois: things like age 0..100 make sense in schema languages, but not in programming languages (eg in computing averages, we sum the ages, and now go out of bounds.)

DaveR: for more complex things, is rif iri a proxy
... iri has lexical form, is not an object

chrisw: understand now that sorting mechanism is very coears grained
... this is just adding a little more flexibility, but not much

<sandro> Chris: signature for every rdf property is rdf:uri X rdf: uri [[ not true! ]]

chrisw: and is not a userdefined notion

DaveR: couls use a balnk node or uri

Michael; existential variable

chrisw: trat blank noes as existential varianble

sandro: literals

chrisw: integer 1 does not have uri

sandro: it does

chrisw: integer has uri

josb; both interprested as same, varaiable ranges over domain

michael: someone has to say that this uri represents this integer

axel: so what is issue?

<sandro> Chris: would having a taxonomy of sorts, in which there is something more general, would that address your concern

<sandro> Jos: yes.

<sandro> Dave: I think, so but I'm not sure about rif:iri in this case.

franc: uri issue is difficult

<MarkusK> Jos: both IRIs and various types of literals should be generalised by a more general "RDF resource" sort

franc: programmer has to know that thing is unique id
... alternative is to build in

franc; if we depart from RDF notion we have a problem

chrisw: not there yet but will be

hassan: what would be the sig of p (on whiteboard)?

chrisw: we are concerned just with lexical space

<Harold> Markus, of course we have to be very careful when selecting the right sublanguage of RDFS (such as a 'fixed (layered) architectured' for defining a partial order) to the to avoid these problems, also liaising with the RDF group. Let's use my earlier example: AmphibiousVehicle subClassOf Car, Car subClassOf Vehicle, AmphibiousVehicle subClassOf Ship, Ship subClassOf Vehicle.

michael: sorts are meant to be primitove xml data types, with just a little more
... paly with signatures to constrain

csma: what is rationale not to allow user defined sorts?

michael: mechanism of sorts in logic in limited
... that of userdefined data types is needed

<MarkusK> Harold, I think this is a mine field that we can avoid by making such class hierarchies object-level statements. One can always write vehicle(X) :- Car(X) etc. to capture the same knowledge in RIF. I think this could be an easier solution that does not get us in touch with RDF semantics as part of our very core formalism.

michael: want to do it dynamically
... if syntactically correct, true or not is in application

chrisw: this is at syntactic level, not semantic

csma: if not part of RIF, why bother abouts sigs

michael: to support datatypes

csma: we just need to say that there are signatures

michael: we say that xsd strings are defined here, sigs elsehwere etc

csma: if I have arulethat uses a predicate Older, +int and +int applic specific
... how does this relate to RIF abstract syntax?

<msinte1> Re MarkusK & Harold: in the current draft, we also have the frame part for doing this with # (typing terms) and ## (for building up type hierarchies)

<Harold> Markus, would this mean you could hardly ever reuse the RDF/S language to encode even your simple taxonomies (partial orders) because of concerns regarding how this would scale up to the 'RDF/S full' semantics?

michael: will have signature signature P int X int, str X str

sandro: analogy with types in prog langs

michael: yes

<sandro> Sandro: So this is like Java types, but NOT java classes.

michael: primitive types, not complex

chrisw: does everyone understnd?

frac: not URI

<MarkusK> Harold, I just think that solving RDFS interoperability is an important issue. It is just a very hard problem that our Core should not depend on. We will have a seperate action on how to exactly achieve (some level of) RDFS interoperability. But this need not be part of our Core sort mechanism.

michael: symbol of sort is string and name of sort

franc; when you speak of iri, do you mean a string?

<sandro> MichaelK: IRIs are special strings. <"foo", rif:iri> is not the same as <"foo", xsd:string> The domain of interpretation for the first one is not fixed, where for the second one it is.

michael: symbols of type uri is well defined, but not interpretation could be mapped to anything

chrisw: for sematic web would ingnore source systems
... but some rule languages need more

<sandro> Chris: Does the semantic object (like the integer one) know about the things that refer to it, like "1"^^xsd:int and "http:..../1"^rif:iri ?

<Harold> Markus, that's fine. So we'll need RIF Phases 2 and 3 to work with others in the Semantic Web Activity on the Big Semantic Web Language Convergence :-)

csma: do we want to forec every RIF dialect to do this type checking?

<sandro> Sandro: Do we really want to say every RIF Core implementation has to do syntactic type checking like this?

markus: should be no problem to have semantic checks at the object level

<MarkusK> Harold, I agree. Also to the fact that this might take until "Phase 3" -- that's why I would like to seperate it from the Core ;-)

<sandro> MichaelK: You can ask: ?- P(?x^^int), ?x^^int=?y^^iri

DaveR: sort on a variable is a semantic restriction

<josb> Harold, Markus, for a proposal for RDFS interoperability, see http://lists.w3.org/Archives/Public/public-rif-wg/2007May/0077.html, http://lists.w3.org/Archives/Public/public-rif-wg/2007Jun/0002.html,

chrisw: this is just static

<sandro> Chris: But java does static type checking on variables.

hassan: where do we draw the abstraction line?

<josb> We had discussion about the use of sorts in RDFS in the thread following http://lists.w3.org/Archives/Public/public-rif-wg/2007May/0077.html

axel: if we do this, we should call this "RIF schema"

<sandro> Axel: call this RIF Schema -- because you'll want to re-use these schemas.

axel: don't want to have to include this for every use

chrisw: get to basis solution before discussing variants
... are we all on the same poge for understanding signatues and sorts?

<sandro> Chris: Now that I understand what this is, I consider this new enough information to reconsider whether to have this in core.

chrisw: now that we understand, do we need it?

<Harold> Axel, we discussed the option of a 'RIF Schema' language at the end of the previous session. To avoid competition on the schema or ontology level, this, then, led to the above RDFS/OWL reuse discussion Markus and I had on IRC.

<sandro> Chris: How many people think we need this syntactic sorts & signatures mechanism in Core

<sandro> 11 yeses

<sandro> 3 no's

<mdean> +1 unsure

hassan: at least this, but also support some of DaveR's concerns

chrisw: Dave, you don't need this, but if there were a mechanism to ignore ...?

DAveR: want it to be semantic

<sandro> DaveR: builtins need to semantic domain checking, not this syntactic-level stuff.

DAveR: not just my use, what we specify for library etc.

michael: when define built ins, do we want semantic checks?
... if so cannot do it directly
... if not, define that built ins will give run time errors

<AxelPolleres> Axel: I think dave rather talks about implicit cast sauff than "semantics", ie, whether some string in the lex space of integeer can be put as an argument of an int signature... Let's see at the discussion about conversion and casting whether that is so!

<sandro> Michael: If we want SYNTACTIC checking (instead of run-time checking) then to add two numbers, one by URI, you'd need to do ?x^^int=uri, p(?x^^int, ...)

<AllenG> hello

<ChrisW> scribenick: MarkusK

<sandro> http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax

<ChrisW> Scribe: Markus Krötzsch

XML Schema from ASN

Gary: there should be as simple as possible rules for mapping from ASN to XML
... subclasses as XML choice

Sandro: we may need more background on XSD to understand the details

Gary: leaf classes (w/o subclasses) are just elements (xsd:element).
... classes with subclasses are references to groups.

References: example XSD http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax?action=AttachFile&do=get&target=RIF3.xsd and example instances http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax?action=AttachFile&do=get&target=RIF3.xml

csma: is it the right approach to have a short set of simple rules to translate ANS06 to XSD? We can still tweak the rules later.

Hassan: in general, yes.
... But how shall we prove the mapping to be correct? Requires full specification of source and target languages. And what if the source language changes?
... But I agree on the approach.
... there could be other target languages, such as DTD.

Gary: I favour XML Schema.
... the advantage is that Java developers can use the JAXB toolkit on the XSD doc

Sandro: I agree that we want to have XSD, since many users can exploit this easily.

Poll: Any other target formats?

-> no other porposals

-> participants with prior ideas about target format thought of XSD

-> 2 people did not think of this before

AdrianG: I propose to also have EBNF.

Sandro: there was an agreement last F2F to have a presentation syntax for the semantic documents, being human readable. This syntax is not related to implementability issues.

csma: ok, so you, Hassan, raise the question of whether we can ensure rules to be correct. Do you have another approach in mind?

Hassan: No.
... I agree on the methodology.

Francois: May we need additional expressivity beyond XSD in the taget language?

s /taget/target/

<sandro> Francois: for instance constraints like: every variable must be declared before being used. -- we can't say that in XML Schema.

Fraoncois: an example are conditions required in compilers that cannot be defined in context-free grammars. An example is the requirement of declaring each variable before using it.

s /Fraoncois/Francois/

AdrianG: But I would not go for a context-sensitive grammar.

[general agreement]

csma: the requirement of first declaring variables need not be enfored by the schema, but can be checked by translators.

Harold: there is a tool named Schematron that extends XSD by some context-sensitive aspects. We could use this.

<sandro> Sandro: I'm comfortable with saying we use XML Schema for what it works for, and any more expressive power we want, we use natural language.

<sandro> Sandro: (and maybe some other tool will come along to help use formalize the extra stuff, but let's not worry about that now.)

<sandro> (general agreement)

<Harold> Here's a pointer: http://wiki.ruleml.org/Schematron

Also see http://en.wikipedia.org/wiki/XML_Schema_Language_Comparison

for a more general discussion of the subject.

DaveR: I would like to undestand better how the use of XML groups works before making definite decisions.

csma: I think we should first understand the translation rules.

<agiurca> For example, it would be good to see the Uniterm implementation in XML Schema

<agiurca> In XML schema types derivation is done with xs:restriction and xs:extension. Then extensibility principles should cover this too

<sandro> http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax#preview

<sandro> http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax

[discussions on which document to project on the beamer]

Dave: I was wondering why you cannot use complex types instead of groups, but I now understand that this is a syntactic restriction of XML.

<agiurca> one very important issue is xs:redefine which can

<Harold> Gary, one reason to keep <op><Const>perishable</Const></op> fully striped rather than type-skipping it to <op>perishable</op> is to have a unique place to put in XML attributes such as as the sort attribute, e.g. <Const sort="http://compliance/terminology#perishable">. Otherwise, we would need to be prepared to look for such attributes in various role tags such as <op>, <org>, ...

Gary: the problem is that you want to have a choice of other choices. You can use group references to implement this nested joice.

<agiurca> one very important issue is xs:redefine which cannot be used nested...

<agiurca> +1 Harold

Hassan: I dislike the name "group" when we mean nested choices.

Gary: well, that is XML terminology we cannot change.

<Harold> Hassan, in DTD groups were expressed as entities, as in: <!ENTITY % TERM "(Const | Var | Uniterm)">

<Harold> where TERM acts like a 'macro': an 'invisible' non-terminal.

Adrian: XSD has mechanisms to define new types, extending or restricting them. Couldn't we use those structures for our case?

Gary: groups are more appropriate, since it is not required to mirror the UML in XML.

<Harold> ... 'invisible' in the sense of 'not shown in the XML markup'.

Adrian: so CONST and TERM are independent, the former not being a subclass of the latter?

csma: why should this be enforced?

Adrian: just to maintain the meaning from ASD.
... but it is not a problem to keep it as it is, if we do not want to mirror the UML structure.

<Harold> Adrian, the 'meaning' is preserved by a kind of metalevel type skipping: Every Const is a TERM, so you only need to show the Const -- you know it must be a TERM.

Gary: Harold talks about role stripes and type stripes, and his schema tends to skip role stripes, whereas I try to skip the type stripes.

<scribe> Scribe: PaulaP

Sandro: parsers will not be schema-driven

Harold: it is not context free

Francois: there might be some problems when transporting parts of programs

<sandro> I think I said "not all parsers will be schema-driven".

<sandro> :-)

<ChrisW> scribenick: PaulaP

<agiurca> If you write <op>perishable</op> then where you will encode the type?

Christian: we design the XML syntax for translation

Francois: it is more complicated

Harold: everything is self-describing and we might loose this

<Harold> Adrian, again one reason to keep <op><Const>perishable</Const></op> fully striped rather than type-skipping it to <op>perishable</op> is to have a unique place to put in XML attributes such as as the sort attribute, e.g. <Const sort="http://compliance/terminology#perishable">. Otherwise, we would need to be prepared to look for such attributes in various role tags such as <op>, <org>, ...

<agiurca> I agree

ChrisW: comments against type stripe skipping

<agiurca> As you say <op><Const>perishable</Const></op> is the appropriate

Sandro: skip also in the case of multiple properties or not?

Gary: yes, in this case too

<Harold> I think Gary does a kind of metalevel type skipping as in XML DTD entities for TERM or XML Schema groups, and I'm very fine with that kind of type skipping.

Sandro: consider that you have two child elements for two properties

Gary: skip if put under declare

Sandro: I suggest we don't use attributes

<sandro> Gary-Stripe-Skipping: Skip class stripes, when there is only one class.

Harold: goes also for artificial stripes

Christian: does this change the rules?

Harold: it was an offer to Gary as a compromise

Christian: is it simpler to implement if we don't skip any stripe?

Benjamin: people will not have the schema in their head

Christian: is that an argument in favour of non-stripping?

Benjamin: could a switch be used?

<agiurca> I vote against implementing subclassOf from asn06 using xs:choice

Christian: you can still do the stripe skipping if you like
... but simpler for implementation if not skipping stripes

<Harold> A good compromise seems to be "fully striped" ("Object Oriented").

Hassan: could we look at an example for both proposals?

Gary: just imagine more tags

Sandro gives an example

<agiurca> If CONDITION is an abstract type then one of its concrete subclasses is, for example, Uniterm

<agiurca> then Uniterm must be implemented as a subtype of CONDITION

Adrian: why do we need this?

<agiurca> We can encode either <Var>x</Var> or <Var rif:name"x"/>

Christian: I thought that everybody is in favour of no stripe skipping...so fully striped

Hassan: who suggested to have modes?

<agiurca> Sorry <Var rif:name="x"/>

<Harold> "fully striped" version of http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax?action=AttachFile&do=get&target=RIF3.xml contains <Uniterm><op><Const>delivered</Const></op> ... </Uniterm>.

<agiurca> I guess the name of the variable in XML syntax is a local name in the form of a xs:NCName instance

<Harold> (instead of <Uniterm><op>>delivered</op> ... </Uniterm>)

Hassan: from the full thing you can have the stripe skips if you don't need that information...a collapsed syntax

<Francois> Chris: we are talking about adding sorts to this syntax.

Christian: Gary, is there just a small change to your rules?

Gary: I don't think so

<agiurca> May be it would be good to discuss the full syntax

Harold: languages exist that are hyper-typed

Christian: are there any objections to fully-striped?

<agiurca> +1 for full syntax

Christian: the proposal of Hassan makes the implementation more complex

Francois: tag minimization in SGML

<sandro> Francois: This is like SGML Tag Minimization -- removed from XML

Francois: remove tags if you know from the context what is missing
... we can make a smarter markup for RIF later

<agiurca> +1 to Francois proposal for a full markup

<sandro> +1 Francois let's use stupid markup until someday RIF is criticised for that.

Francois: if we need such a markup

<Harold> ('hyper-typed' in the sense of 'redundantly type tagged' such as in <TERM><Const>...</Const></TERM>.)

<sandro> ("stupid markip == fully-striped)

Christian: rulesets with a huge number of rules might be also used

Francois: simplifications might be blocking for the future developments of RIF

Christian: we can ammend the rules Gary proposed

Adrian: ASN06 subclass explanation needed
... why is this implemented with choice

Sandro: you're doing data modelling and not abstract syntax
... model variables with names that are strings
... do we say that strings need to have a datatype string given?
... another question regards the use of datatype as element name

Francois: there is one rule for using atttributes vs element names
... put attributes if you want to be recognized as soon as possible

Hassan: there are other rules too
... but nothing is definite

Francois: whatever we choose we should have a reason for it and use it uniformly

Benjamin: for forward compatibility, complex expressions later - elements should be used

Christian: datatype as an attribute, you can any datatype there

<Harold> Sandro, I think we don't want to have a redundant <name> stripe on the leaf level all across our XML trees: everything at the leaf level ends in some name, so we can put names directly into leaf level type tags like <Var>, <Const>, ...

Benjamin: from a practical point of view, elements should perhaps used for cases where complex expressions might be used

Christian: support for child elements

<sandro> PROPOSED: for [2.1. Should string values be child-elements or attributes?] answer is: Use Child Elements

Christian: question - string values as child elements or attributes

Harold: XML attribute vs. element
... this is the question

Sandro reads the proposed resolution

<sandro> PROPOSED: for [2.1. Should string values be child-elements or attributes?] answer is: Use Child Elements

<sandro> RESOLVED: for [2.1. Should string values be child-elements or attributes?] answer is: Use Child Elements

Christian: objections to that?

Hassan: we should make rationale explicit

<sandro> Benjamin: "for sake for forward compatibility" (rationale)

Christian: could we conclude on stripe-skipping?
... Gary wants simple rules
... proposes to remove first sentence of rule 2

Gary: it won't work
... you need to say what to do with these classes

Sandro: put an element there

Gary: you need to worry about the properties
... I reuse here complex types
... it will increase the number of Java classes

Sandro: the normal case is that there are several different classes
... you have then two XML levels...what the type is and what kind of values

Gary: you generate a lot more classes if you don't stripe skip

Adrian: it generates classes when instantiated

Gary: it generates a class for every complex type

Hassan would like to see an example

Christian: we should care about ease of implementation

Hassan gives an example

scribe: a class with 3 subclasses
... and the 3 subclasses have no subclasses
... given so as to understand how the implementation Gary uses behaves

Gary: I don't think it's a class issue, but a property issue
... you have to look at the schema
... not at the instances

Sandro: why need a class for formula?
... you don't need such a class

<Harold> Gary, a JAXB optimizer could still get the effect of your leaf level type tag skipping, but still show them for interchange purposes: basically, the tool would analyze *role-type paths*, notice which roles are unique on their own in some context, and remember that information, so that such uniquely *role-identified classes* would not need to be stored in that context repeatedly.

Sandro: it should be a Java class called Var

Harold explains his proposal

Gary: yes, you could do it that way

Sandro: I don't think it is bad if we have more Java classes

Gary: in my proposal there is no formula class, but a class for forall

Christian: each class in the asn06 be a class
... what do we want as the target?
... properties should not correspond to Java objects, just classes in asn06

Adrian: why?

<agiurca> Scribe: AdrianGiurca

<agiurca> scribenick: agiurca

scribenick agiurca

csma: Lets take the issues one by one and discuss them
... all classes in asn06 and only them should be complex types

<sandro> ACTION: Gary to try to change his implement to support fully-striped serialization [recorded in http://www.w3.org/2007/06/02-rif-irc]

<rifbot> Created ACTION-297 - Try to change his implement to support fully-striped serialization [on Gary Hallmark - due 2007-06-09].

<sandro> Harold: I'm happy to help.

sandro: I guess this is not really necessary

csma: What is the filling of the group if we would use an RDF/XML normal form?

sandro: I don't expect a resolution on that now

csma: lets answer now "yes" on the 1.2 Section

francois: traditionally in compilers is a distinction between parsing and semantic analisys

<Harold> Sandro, what would an RDF parser do with the repeated <arg>...</arg> children of <Uniterm> <op><Const>delivered</Const></op> <arg>...</arg> . . . <arg>...</arg> </Uniterm>? They are meant to be ordered as in the detailed <Uniterm> <op><Const>delivered</Const></op> <arg index="1">...</arg> . . . <arg index="N">...</arg> </Uniterm>

<Harold> with an XML attribute index.

sandro: the software which use the RIF rules must have access to the RIF schema

<Harold> s/muats/must/

<sandro> Dave: This question (1.3) is like SOAP -- do we have general encoding rules, or require app-specific data knowledge.

francois: the schema must be accessible for tools

csma: the RIF schema is the schema for the envelope in the comparison with SOAP

<sandro> move on!

sandro: lets move on

csma: on 2.1 We agree on child elements
... there are different implementations on the proposed solutions?

Harold: It is a good idea to have an URI as an xml attribute
... we don't want to have so many namespaces

francois: are namespaces prefixes easy to process as attributes values?
... there is not much support for attribute values

DaveReynolds: We agree that a datatype is defined with an URI

Harold: I am in favor of full URI for datatypes

csma: lets move on

<sandro> Francois: I'm uncomfortable with Gary's proposal because it gives extra parens. XML is our parens.

<sandro> Francois: and Adrian's, because it's quite redundant.

<sandro> Francois: I don't like "No" because XML standard does not tell you how to do it.

<Harold> We should use 'No' for "2.2. Should datatypes look like class names?" since we want to have webizing with a full URI.

<sandro> consensus: it's pretty much a coin flip.

<Harold> I didn't quite understand the multiple type argument. It seems to apply to both options for 2.2.

<sandro> DaveR: we've tried to separate the qname/iri/curie issue.

csma: lets go to the next one (2.3)

<Harold> Gary, in RIF we currently have webizing like <Const iri="http://homepage/john">John</Const>.

Hassan: what's the benefit of the first one?

DaveReynolds: RDF plain literals use a language tag

<Harold> For "2.3. Should strings require a datatype?" I think we should have 'Yes' as in <comment><Narrative lang="en.US">This is our main rule. Please read it carefully.</Narrative></comment>.

Francois: a language atribute is resonable since can help in explaining the concept

Harold: I suppose it is useful to have a lang attribute within a surrounding class, e.g. Narrative

DaveReynolds: lang attribute helps for the RIF internalization
... use xml:lang for that

<sandro> Sandro/DaveR: add "text" to the asn, and serialize it with an associated xml:lang.

<msintek> Scribe: Michael Sintek

<msintek> scribenick: msintek

Gary: unly useful if multiple texts are allowed, thus allowing internationalization

<sandro> Sandro: do we build that into text or just use "text*" everywhere we would otherwise use text?

<sandro> Hassan: (some sort of Why I18N This Way?)

<sandro> DaveR: The metadata that we mandate as part of RIF -- do we allow alternative-language names for rules, and comments?

<sandro> csma: asn: class Text { property xml:lang : xsd:string ; property value : xsd:string }

<sandro> sandro: I was imaginaing "text" as a kind of built-in, but either way.

<sandro> (built-in makes it easier to control the serialization.)

<sandro> (I think)

<sandro> general consensus around using some kind of "text" type.

csma: only pieces of text that "belong" to RIF (comments) we have internationalization

<sandro> csma: for when RIF needs comments or names for rules, etc.

<sandro> s/class Test/class Text/

no resolution

next: 2.3. Should strings require a datatype?

Markus: SPARQL distinguishes typed and untyped literals
... plain is lower than then one with xsd:string

Sandro: wants to read file without schema in head

<sandro> agreed --- issue 2.3 follows from issue 1.3 We need xsd:string to be specified if we want to allow parsing without a schema.

<MarkusK> typed xsd:strings and untyped plain literals are different in RDF: http://www.w3.org/TR/rdf-concepts/#section-Literal-Equality

<MarkusK> Dave: yet, they may represent the same semantic entity

<sandro> general consensus re connecting 2.3 and 1.3

Benjamin: variables exposed to people, so have similar issues
... another aspect: do we want at the level of the whole rule base some language specified

<sandro> sandro: I think all the "strings" in RIF should probably really be texts.

<sandro> sandro; xml:lang tag is normally inherited.

<PaulVincent> XML enumerations vs issue 2.3: see http://www.w3.org/TR/xmlschema-2/#src-multiple-enumerations - surely this is how to handle enums in XML docs?

Benjamin: where will we have strings that are not treated as text
... name of predicate, argument etc. get exposed to users

<agiurca> <Const xml:lang="en" iri:="http://www.example.com/classes#shoppingCart">shoppingCart</Const> is the same with <Const xml:lang="de" iri:="http://www.example.com/classes#shoppingCart">Einkaufenkarre </Const> ?

<MarkusK> s /Einkaufenkarre /Einkaufswagen/

<MarkusK> IMHO this is not the same.

<agiurca> But the IRI's are the same

will likely use metadata to solve this

<MarkusK> ah, sorry -- I withdraw my comment

next: 3.1. Should identifiers be child-elements or attributes?

Harold: many prefer attributes

csma: Benjamin does not want them

<sandro> (discussion of the fact that we're making resolutions when some people (Chris, MichaelK, Jos, Axel) have left to an ad-hoc breakout.)

<sandro> PROPOSED: On [3.1. Should identifiers be child-elements or attributes?] answer: we'll use attributes

<sandro> DaveR: I don't understand how this fits into RIF Core.

DaveR: seems at odds with sorts as discussed this morning

<sandro> Sandro: implicit in my framing of 3.1 is that everything has an IRI, and IRI's work like object references. They are used in serializing and deserialiing graph-shaped data structures.

<sandro> DaveR: So I'm happy with this proposal as a Preferences.

<Harold> I know that MichaelK is fine with things like <Dog iri="http://hawke.org/2005/Tzuzumi" />.

<sandro> (ie general consensus of the group.)

next: 3.2. If attributes are used, should they be allowed directly on properties (as above), or should we force a class stripe

Sandro: relevant in graph-shaped data structures

<Harold> I think for 3.2., <companion iri="http://hawke.org/2005/Tzuzumi"> is out of question.

<Harold> Abbreviations like this make RDF/XML hard to read.

Sandro: full def. is somewhere else anyway

<agiurca> +1 Harold

csma/Sandro: problem does not arise in asn now, but might later

<Harold> Sandro, this is an untyped object reference within a typed object.

<sandro> Sandro: I'm okay with leaving out the "dog" here because it's really a reference --- a whole bunch of properties are elsewhere -- so the type can be elsewhere, too.

DaveR: gives example for rules that are graph-structured (not just tree)

<sandro> DaveR: the question is whether RIF might want to use structure sharing, to maybe have a graph data structure.

<Harold> This looks (almost) like untyped operations in assembly languages.

<Harold> Even in (cyclic) RDF graphs the nodes are typed, and in a semantic language we should mention those types when we refer to them.

csma: thinks there is no consensus

<Harold> Also, we decided for fully striped.

<sandro> PROPOSED: resolve [3.2. If attributes are used, should they be allowed directly on properties (as above), or should we force a class stripe] by saying "on properties" ---- mostly because we want the objects to be declared in one place, and have pointers look like pointers.

<sandro> csma: I'm not ready to make a resolution because it relates to data-binding which we haven't talked about enough yet.

<sandro> ADJOURNED.

<scribe> done for today

<sandro> re-start 9am sharp. please arrive early.

<Francois2> bye.

<CGI546-allen> quit

Summary of Action Items

[NEW] ACTION: Gary to try to change his implement to support fully-striped serialization [recorded in http://www.w3.org/2007/06/02-rif-irc]
[End of minutes]

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