See also: IRC log
<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
<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."
<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
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