See also: IRC log
<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
http://www.w3.org/2005/rules/wg/wiki/Core/Horn_Rules_Alternative
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)
<ChrisW> sandro is on Arch/XML_Syntax on the wiki
sandro: (presenting slides)
http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax_Issues_2
<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:
A. RDF?
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
http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax_Issues/Identifying_Rulesets
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
http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax_Issues/Identifying_Rulesets
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?
name
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.
http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax_Issues/Positional_Arguments
<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>.
http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax_Issues/Positional_Arguments
http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax_Issues/Positional_Arguments
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!
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]