RIF F2F8 - 28 Sept 2007

28 Sep 2007

See also: IRC log


[IBM], Gary_Hallmark
Chris Welty
Stella Mitchell, Axel Polleres




<StellaMitchell> ScribeNick: StellaMitchell

<ChrisW> Scribe: Stella Mitchell

csma: showing current abstract syntax for rules

<ChrisW> who is CGI396

csma: problem with extensibility (for example for existential quantification), with the current scheme
... another issue: a ground class it still enclosed in a forall

harold: we resolved to enclose every clause in forall

csma: no, not every clause, every variable
... and, it we did resolve it, it was a bad decision

sandro: we can change our minds only if we get new information

csma: in summary, it is not extensible, ground clauses are enclosed in forall, and a minor issue that metadata is attached to a forall

<sandro> We're calling now IgorMozetic

csma: in June, I proposed an alternative, that doesn't change the semantics and only changes syntax a little


harold: we cannot syntactically enforce that the forall contains the approproate varialbes, because the syntax is context free

csma: that problem exists in both designs
... GaryH agreed that my proposal is acceptable

<ChrisW> CGI396 who are you?

<ChrisW> IgorMozetic, can you hear OK?

BobM: asking about cardinality constaint on clauses

<IgorMozetic> yes, I hear fine

csma: because of the design, if you have a rule, you must have a clause

<sandro> CGI396? Hello?

csma: (presents a minor change to his original proposal)
... clause was renamed to conditionalWithQuantifiedVariables and it moves above the forall
... I propose we adopt this symtax in place of the current one

jos: question - if there is implies without forall, do all vars still have to be quantified
... i.e. will free variables be allowed?

csma: the situation with free variables is the same in current syntax and this one

jos: I don't agree with the text of the proposed resolution - because of the particular wording
... but I have no objection to the design

harold: rule is a word that is too specific to FOL

csma: 1. we have to have that stretch anyway 2. this proposal only means the structural model, not the exact wording

daver: there is a use case for having metadata at the top level, and it doesn't hurt anything

harold: it violates a minimalist design

csma: our discussion time for this item is over, and we weren't able to resolve, so we will raise an issue

<ChrisW> ACTION: harold to raise issue about new structural model for syntax of BLD rules [recorded in http://www.w3.org/2007/09/28-rif-minutes.html#action01]

<rifbot> Created ACTION-353 - Raise issue about new structural model for syntax of BLD rules [on Harold Boley - due 2007-10-05].

(csma will send slides to the group)

XML Syntax

<ChrisW> sandro is on Arch/XML_Syntax on the wiki

sandro: (presenting slides)


<ChrisW> http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax_Issues/Root_Element

sandro: issue: what should root of BLD look like?

<ChrisW> harold suggested rif:RIF for the root element name

<ChrisW> http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax_Issues/Root_Element

jos: why did you use curie and not uri?

michaelK: and you didn't define "rif:" but you don't need it anyway

sandro: curie: I made it optional

jos: xml tools will not know about curies

sandro: but they will not know about dialects either

michaelk: it's ambiguous, because xml will think it's a namespace

daver, jos: no, that isn't right

harold: suggestion:
... about identifying dialet

axel: awkward for inter-dialect interchange

(writing overview of issues on the board);

1. use of curies

2. structure of uri's for dialect identification

3. how to identify dialect

sandro: my assumption was that I should use curies wherever possible

options for 3:

a: dialect attribute

b: rif: dialect document

MikeDean: why datatype attribute instead of object property for dialect?

<AxelPolleres> Side remark: CURI -> CIRI ?

<Harold> Option F: <rif:RIF xmlns="http://www.w3.org/2007/rif/BLD" xmlns:xs="http://www.w3.org/2001/XMLSchema#"> . . . </RIF>

<Harold> <rif:RIF xmlns="http://www.w3.org/2007/rif/BLD" xmlns:xs="http://www.w3.org/2001/XMLSchema#"> . . . </rif:RIF>

sandro: rif:Document vs. rif:BLDDocument

harold: and I proposed another option above in irc

<ChrisW> Chair: Christian de Sainte-Marie

<AxelPolleres> I think we should not use different namespaces per dialect, that seems to lock out reuse of common elements between dialects.

sandro: what would use the default namespace?

harold: the second namespace is for extensions

michaelK: but it would be difficult to identify the dialect

harold: we need a modular approach

axel: concern (?)

(back to issues lists)

4. namepsaces

harold: do we want a tree of dialects or a deck (lattice) of them?

sandro: the issues we need to solve today are:


B. Root = Dialect Specific

C. Root is "Document or RIF"

<AxelPolleres> Harold: Exactly what you say is why I want the core components to be labeled rif and not rifBLD... BLD already makes some restictions on the use of the core components (e.g. no forall in bodies, etc. which other languages would maybe want to allow)

sandro: any objections to making it not dialect specific?

harold: wants it be dialect specific

straw poll: should the root element be dialect specific?

any strong opinions on this?

show of hands

proposed: for WD2, the root element will not be dialect specific

<sandro> resolved: for WD2, the root element will not be dialect specific

<ChrisW> RESOLUTION: for BLD WD2, the root element will not be dialect specific

sandro: discussing name of root element

harold: "document" is too general

sandro: no, it would be rif:Document or rif:RIFDocument
... because I want to know what it is from an object perspective

MichaelK: let's be compatible with the other standards

<IgorMozetic> I vote for rif:RIF (for consistency with others)

proposed: root element will be rif:Document

<sandro> RESOLVED: root element is rif:Document

<ChrisW> RESOLUTION: root element is rif:Document

vote outcome:

rif: Document - 4 for, 0 against
... RIFDocument 2 for, 4 against
... RIF 5 for, 1 against

sandro: issue about identifying rulesets

csma: suggests "name" instead of "id"

<Harold> ID/IDREF in XML: http://www.w3.org/TR/xmlschema-2/#ID

<Harold> <length

<Harold> fixed = boolean : false

<Harold> id = ID

<Harold> value = nonNegativeInteger

<Harold> {any attributes with non-schema namespace . . .}>

<mdean> http://www.w3.org/TR/xml-id/

<Harold> Content: (annotation?)

<Harold> </length>

sandro: we decided at f2f4 to use IRI

daver: re: options b, typcially they can still be relative uri's


sandro: and I want to add another option to this list, for xml:id

daver: use relative uri's not ids
... will make rule merging easier

harold: it's legal to attach an id to any element
... mikedean pointed us to a 2005 draft about ids, above in irc

daver: suggested using rdf:about or something similar, instead of xml:id
... (and would not use curies, because they are more controversial)
... rdf:about is an attribute
... but I was not suggesting rdf:about exactly - just a relative uri in general

sandro: the basic choice is between ids (incl xml machinery) and uris

csma: ids restricting to one per document

daver: ids are a problem for merging

mikedean: rules should be uniquely named only within a ruleset?

csma, sandro; no

daver: with rdf syntax, we would get some processing for free - but that is a different issue

csma: poll between relative uris, and ids

vote outcome:

relative uris: 8

ids: 0

s/8/8 for/0 against/

s/ids: 0/for 0/against 1/

<mdean> scribenick: mdean

continue ArchXML Syntax Issues


discussion of attribute names rdf:about or rif:<something>

rif: options: about, id, ident, uri, iri, oid
... iri is used elsewhere, which could cause confusion

globalID, globalName

Harold: also need attribute to refer to ruleset or rule?
... or is this only a handle for metadata?


Harold: oid is for frames only

take out uri and iri

Jos: identifier or id, not ident

Harold: possible confusion between id and xml:id

MichaelKifer: uniqueness requirements?

Chris: architecture of Semantic Web assumes URI are unique - not our problem that we can't enforce it

csma: could we use rif:about and express equivalence to rdf:about?

Sandro: mapping required, but not automatic

name: 6 prefer, 0 object

globalId: 1 prefer, 1 object

about: 1 prefer, 0 object

identifier: 3 prefer, 0 object

Chris: nobody expects names to be unique, but do expect identifiers to be unique

reconsider id?

Sandro: hasIRI?

Harold: metadataAttachmentPoint

<AxelPolleres> i like rif:tafkab

straw poll #2

name: 1 prefer, csma objects

id: 2 prefer, jos and chris object

identifier: 8 prefer, 0 object

hasIRI: 1 prefer, Adrian and Axel object

metadataAttachmentPoint: 1 prefer, various object

<sandro> PROPOSED: To identify rules and rulesets (and other syntactic objects needing identifiers) we'll use rdf:about or rif:identifier in the next draft.

<sandro> PROPOSED: To identify rules and rulesets (and other syntactic objects not otherwise having identifiers) we'll use rdf:about or rif:identifier in the next draft.

<sandro> PROPOSED: To identify rules and rulesets (and other syntactic objects not otherwise having identifiers) we'll use rdf:about or rif:identifier in the next draft. This is envisioned for metadata and should not affect the semantics.

<sandro> RESOLVED:: To identify rules and rulesets (and other syntactic objects not otherwise having identifiers) we'll use rdf:about or rif:identifier in the next draft. This is envisioned for metadata and should not affect the semantics.

<Harold> Comment: So, as we discussed, the identifier attribute is not meant for names within the language.


<AxelPolleres> I propose: To identify order/position of arguments in uniterms (and other syntactic objects needing order) we'll use an rdf:position attribute in the next draft.

<AxelPolleres> ... seems to be option E.

<AxelPolleres> <arg position="1"> ... </arg>

Sandro: doesn't fit normal striping

Chris: perhaps fold position into parameter names

<Harold> Axel, Yes, we have in the draft that Opt. A is interpreted as

<Harold> <Uniterm>

<Harold> <op>...</op>

<Harold> <arg index="1"><...></arg>

<Harold> <arg index="2"><...></arg>

<Harold> <arg index="3"><...></arg>

<Harold> </Uniterm>

Axel: using the same attribute for name and position precludes named positional arguments

Michael: order is determined by semantics, can be done in XML Schema, why do we need it in instances?

csma: can imagine cases in other dialects where order of rules matters, e.g. production rules

<Harold> In http://www.w3.org/2005/rules/wg/wiki/Core/Positive_Conditions, section "XML serialization" we have

<Harold> - arg (argument role, positional/non-positional without/with optional 'index' attribute)

<DaveReynolds> Possibly helpful discussion of issues of ordering in XML: http://www-128.ibm.com/developerworks/xml/library/x-eleord.html

<AxelPolleres> another argument against using the same attribute for position and name nedds care excpluding position names as slot names.

csma: production rules typically distinguish sequential or not - necessary for round-tripping

Chris: issue: does order need to be indicated in RIF document?

<Harold> So like OPTION C2 and HTML reads <li><...></li> in sequence, so does the current draft reads <arg><...></arg> as <arg index="i"><...></arg>.



Dave: XML parser can reorder arguments, though most don't

<csma> Gary, the discussion is whether (and how) to indicate order in documents, when the schema contains that information and the semantics as well

Dave: InfoSet is ordered

Bob: XML Schema can specify order

<csma> Chris: we are dealing with the case where the schema specify order

<GaryHallmark> +1 for option A.

Bob: implicit ordering of arguments

Sandro: consider rule set where rules are not ordered

csma: support schemaless parsing into unordered structures

Harold: preserve editing order
... e.g. as in Protege

<GaryHallmark> +1 for Harold's point. XML *is* ordered, and that's often a good thing

csma: assume ordered until semantic level

Axel: ruleset implies unordered
... should we use ruleprogram instead :-)

Dave: may impact ruleset merging - motivates unordering of RDF

<GaryHallmark> I want my rules in an XML document that I can edit, store, transmit, etc. Not in some unordered pile of triples...

csma: ordered for parser not semantics

<Harold> As I said, the Protege group at SMI, had the same discussion about whether to preserve class-definition order: although the semantic will *interpret* the definitions in an unordered manner (the order does not matter semantically), the Protege group decided to preserve the editing order so people can roundtrip through the tool without losing their editing order information (very helpful for documentary purposes).

Gary: XML is ordered

Dave: concerned about assuming everything is ordered

Michael: just make sure you preserve the semantics

csma: want some rules to be processed as ordered, property of ruleset not schema

<Harold> For multiple 'includes' the inclusion order could also be preserved for inspection and editing purposes, again without affecting the unordered semantic *interpretation* of the merged ruleset.

csma: what if new parser lost order?

<Harold> Bob, right, the repeated arg elements in

<Harold> <Uniterm>

<Harold> <op>...</op>

<Harold> <arg><...></arg>

<Harold> <arg><...></arg>

<Harold> <arg><...></arg>

<Harold> </Uniterm>

<Harold> are read as

<Harold> <Uniterm>

<Harold> <op>...</op>

<Harold> <arg index="1"><...></arg>

<Harold> <arg index="2"><...></arg>

<Harold> <arg index="3"><...></arg>

<Harold> </Uniterm>

Sandro: doesn't make sense to order properties

Axel: assuming XML syntax close to abstract model
... UML doesn't provide good way to indicate order

Chris: is redundancy needed in document so it can be processed without syntax specification

Sandro: ASN specifies ordered in some cases where it's not necessary

Dave: RDF is such an unordered representation

Sandro: output of RDF mapping is horrendous with lots of lists

straw poll: indicate order or not

Gary: how to tell from schema?

Bob: sequence vs. all

Gary: some restrictions on all

Michael: repeating elements OK

<Harold> "The all group (which provides a simplified version of the SGML &-Connector) is limited to the top-level of any content model. Moreover, the group's children must all be individual elements (no groups), and no element in the content model may appear more than once, i.e. the permissible values of minOccurs and maxOccurs are 0 and 1. "

<Harold> http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/

<Harold> (more precisely: http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/#groups)

Gary: editor could provide presentation order e.g. by label

<AxelPolleres> scribe: Axel Polleres

<AxelPolleres> scribenick: Axel Polleres

<AxelPolleres> michael: restriction on order in XML not "severe" (michael: pls post a link?)

<AxelPolleres> ... discussing XML schema ALL directive.

<AxelPolleres> Bob: ALL doesn't indicate that the elements should be *treated* unordered

<AxelPolleres> Chris: Do we want to preserve order where not necessary by semantics, e.g. slotted terms?

<AxelPolleres> Axel: I am worried about extensibility if we now go for the order to be always reflected.

<Harold> Axel, like in HTML you are allowed to say

<Harold> <li><...></li>

<Harold> <li><...></li>

<Harold> <li><...></li>

<AxelPolleres> Chris: this is not the question here.

<Harold> we can say

<Harold> <arg><...></arg>

<Harold> <arg><...></arg>

<Harold> <arg><...></arg>

<Harold> and parse it as

<Harold> <arg index="1"><...></arg>

<Harold> <arg index="2"><...></arg>

<Harold> <arg index="3"><...></arg>

<AxelPolleres> Sandro (whiteboard): Is the semantics that it's not ordered to be reflected in every instance document?

<AxelPolleres> scribe-hat off: Harold, I like that option, it caters for both sides in some sense.

<AxelPolleres> Michael and Sanrdo: further arguing whether this plays a role for parsers, e.g. reading into a database.

<AxelPolleres> michael: sql databases are ordered (rela alg. is not)

<AxelPolleres> Bob: if we stick the information in the xml, what benefit do we get?

<AxelPolleres> Christian: Sandro, if you want to put it in a triple store, it is not a question of the parser.

<AxelPolleres> Sandro: unordered saves trouble in storing in triplestores, whereas order needs to be encoded in lists or by assitional sequence attributes.

<Harold> Axel, Yes, this is part of OPTION A.

<AxelPolleres> scribe-hat off: Harold, but one is on pro and the second is on con side.

<AxelPolleres> chris: who prefer to have order indicated?

<AxelPolleres> 4 pro / 8 against

<AxelPolleres> chris: who would object order being indicated?

<AxelPolleres> 1 (bob)

<AxelPolleres> chris: who would object to not indicate order?

<AxelPolleres> 2 (sandro, axel)

<Harold> Axel, as you said "it caters for both sides in some sense".

<AxelPolleres> sandro: i can't do the implementation I want, then.

<AxelPolleres> harold: It is not so tragic, in reality.

<AxelPolleres> christian: bob's objection is different from sandro's objection, since bob said it doesn't make sense, whereas sandro says he cannot use his tools anymore.

<AxelPolleres> chris (chairhat off): the fact that you can indicate oreder in XML (schema) seems a stronger argument for me.

<AxelPolleres> sandro: but you don't know when order doesn't meatter then.

<Harold> Sandro's tool, which disregards the order of rules in a Ruleset etc, can still be used, but people will often also keep the original input Ruleset document because they cannot roundtrip through that tool.

<Harold> (So, the problem is a kind of duplication of the Ruleset, not that the tool is unusable.)

<ChrisW> gary - if you want to get on the queue, do it on IRC and the scribe will tell me

<AxelPolleres> michael: ordered case is the more common one.

<AxelPolleres> axel: would you then indicate unordered explicitly?

<AxelPolleres> gary: order for AND is important, if we allow built-ins!

<Harold> Reading/Parsing <arg><...></arg> as <arg index="i"><...></arg> for the ith element is like HTML's use of <li><...></li>: a position-dependent default value for the index attribute.

<AxelPolleres> bob: you may want to preserve the order for some cases

<AxelPolleres> sandro: then don't use BLD

<AxelPolleres> christian: OMG PRR has ben voted an alpha specification

<AxelPolleres> chris: lunchbreak!

Summary of Action Items

[NEW] ACTION: harold to raise issue about new structural model for syntax of BLD rules [recorded in http://www.w3.org/2007/09/28-rif-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/09/28 17:33:05 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.128  of Date: 2007/02/23 21:38:13  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/2./2. structure of uri's for dialect identification/
Succeeded: s/we/why/
Succeeded: s/dialect/dialect?/
Succeeded: s/objectsion/objections/
Succeeded: s/ird/irc/
WARNING: Bad s/// command: s/8/8 for/0 against/
WARNING: Bad s/// command: s/ids: 0/for 0/against 1/
Succeeded: s/precludes named/using the same attribute for name and position precludes named/
Succeeded: s/need/needed/
Found ScribeNick: StellaMitchell
Found Scribe: Stella Mitchell
Found ScribeNick: mdean
Found Scribe: Axel Polleres
Found ScribeNick: Axel Polleres
WARNING: No scribe lines found matching ScribeNick pattern: <Axel\ Polleres> ...
Scribes: Stella Mitchell, Axel Polleres
ScribeNicks: StellaMitchell, mdean, Axel Polleres

WARNING: Replacing list of attendees.
Old list: IgorMozetic Stella Mitchell Mike Dean Adrian Paschke Axel Polleres Jos de Bruijn Paula Patranjan Dave Reynolds Bob Moore Harold Boley Michael Kifer Sandro Hawke Christian Sainte-Marie Chris Welty StellaMitchell MikeDean AdrianPaschke AxelPolleres JosdeBruijn PaulaPatranjan DaveReynolds BobMoore HaroldBoley MichaelKifer SandroHawke ChristiandeSainte-Marie ChrisWelty
New list: Gary_Hallmark

Default Present: [IBM], Gary_Hallmark
Present: [IBM] Gary_Hallmark

WARNING: Fewer than 3 people found for Present list!

Got date from IRC log name: 28 Sep 2007
Guessing minutes URL: http://www.w3.org/2007/09/28-rif-minutes.html
People with action items: harold

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]