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: AxelPolleres
michael: restriction on order in XML not "severe" (michael: pls post a link?)
... discussing XML schema ALL directive.
Bob: ALL doesn't indicate that the elements should be *treated* unordered
Chris: Do we want to preserve order where not necessary by semantics, e.g. slotted terms?
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>
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>
Sandro (whiteboard): Is the semantics that it's not ordered to be reflected in every instance document?
scribe-hat off: Harold, I like that option, it caters for both sides in some sense.
Michael and Sanrdo: further arguing whether this plays a role for parsers, e.g. reading into a database.
michael: sql databases are ordered (rela alg. is not)
Bob: if we stick the information in the xml, what benefit do we get?
Christian: Sandro, if you want to put it in a triple store, it is not a question of the parser.
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.
scribe-hat off: Harold, but one is on pro and the second is on con side.
chris: who prefer to have order indicated?
4 pro / 8 against
chris: who would object order being indicated?
1 (bob)
chris: who would object to not indicate order?
2 (sandro, axel)
<Harold> Axel, as you said "it caters for both sides in some sense".
sandro: i can't do the implementation I want, then.
harold: It is not so tragic, in reality.
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.
chris (chairhat off): the fact that you can indicate oreder in XML (schema) seems a stronger argument for me.
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
michael: ordered case is the more common one.
axel: would you then indicate unordered explicitly?
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.
bob: you may want to preserve the order for some cases
sandro: then don't use BLD
christian: OMG PRR has ben voted an alpha specification
chris: lunchbreak!
<sandro> PROPOSED: In WD2 there will be no indication of whether order has semantics in XML instance documents. The issue remains open for future drafts.
sandro/axel: we resolved a workaround for the implementation issue which sandro mentioned before the break during lunch, which we can live with for the moment.
<GaryHallmark> call Zakim when you start...
sandro: we still need a strawpoll: how many people prefer an XML/RDF syntax?
2 pro hands up
s/votes/hands up/
<sandro> we're dialing you in Gary
<sandro> PROPOSED: In WD2 there will be no indication of whether order has semantics in XML instance documents. The issue remains open for future drafts.
<sandro> Note that this implies WD2 will not have an RDF/XML syntax.
christian: (explaining to gary what we did before he dialed in)
<sandro> RESOLVED: In WD2 there will be no indication of whether order has semantics in XML instance documents. The issue remains open for future drafts.
no objections against proposed resolution.
<ChrisW> ACTION: Sandro to open an issue on where order has semantics in XML instance docs [recorded in http://www.w3.org/2007/09/28-rif-minutes.html#action02]
<rifbot> Created ACTION-354 - Open an issue on where order has semantics in XML instance docs [on Sandro Hawke - due 2007-10-05].
sandro: 4th and last issue
... How do we serialize constants?
http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax_Issues/Constants
<Harold> Currently, we have "abc"^^xsd:string
<Harold> http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax_Issues/Constants
sandro: explaining the options outlined on that page.
... Opt A vs. Opt B: type as attribute vs. type as element, (Options to be read with respect to previous resolution )
... Opt C: special distinction for Literals
michael: tag names matter, because schema definition becomes complicated.
sandro: may hamper extensibility.
michael: what about unknown types?
(meta remark: discussing option B)
jos: technically any allowed tag can be done in XML schema.
michael: in Option A type could be anything
dave: ANY doesn't seem to be a solution
jos: in Opt you can say that type is a URI and a STRING inside ...
... ... but in Option B, using ANY you cannot restrict the content to be a STRING
chris: how do you indicate in Option B a variable?
<Harold> From Michael's email, in response to Jos, "Re: comments on BLD draft part I":
<scribe> scribe: Adrian Paschke
<Harold> > 17- section 2.1.2: it is unclear to me why the list of datatypes is
<Harold> > fixed. By fixing this list, every implementation needs to support all
<Harold> > mentioned data types, and no other data types can be used in
<Harold> > meaning-preserving fashion. I propose to make a list of datatypes which
<Harold> > need to be supported by every RIF implementation (e.g. xsd:string,
<Harold> > xsd:integer), and a list of additional data types which are recommended
<Harold> > for use with RIF (e.g. xsd:gYearMonth)
<Harold> The list of data types is not fixed. It is in flux.
<Harold> It is a minor issue, but I am not against recommended data types.
<Harold> Or, maybe, we could use a more general mechanism.
<Harold> We need to think what does it mean for an exchange language to "support" a
<scribe> scribenick: AdrianPa
<Harold> data type. Is it a matter of issuing an error when the lexical space is
<Harold> violated? To support certain inferences? If the latter, then I fail to see
<Harold> what does it mean to be a type "recommended" for use with RIF.
Christian: Opt C seperates seperates lterals from global and local
Michael: They are already seperated
Jos: Opt C makes a distinction between Local, Global and typed literals
Sandro: Does the XML Schema for BLD hard code and check the datatypes?
Jos: needs to fixed in the language and changes to the language are needed
Sandro: Define BLD for unknown datatypes
Chris: Decide if we need other datatypes?
Christian: Are datatypes extensible in BLD?
everyone but Sandro; no objection
<ChrisW> PROPOSED: Datatypes are extensible in BLD
Sandro: Two parties want to interchange some datatype not defined in BLD
... we could make a new dialect
... the parties should make a new dialect
Christian: BLD can be used easily if datatype are extensible
... your rule system will tell you if it can not understand the datatype
Sandro: BLD should not have a custom extension mechanism
Christian: Without a extension mechansimn you always needs to deploy a new dialect
Michael: Deployment of new dialects will be hard
Dave: OWL and RDF already adopted this approach and it was successful
Sandro: Which built-ins
Christian: Update issue about datatype exentsibility
... Reject option B, we are left with C and option A
Jos: We need to be consistent in presentation syntax, abstract syntax
<Harold> We adopted a uniform element name <Const> and don't even have element names <Rel>, <Fun>, and <Ind> distinguishing, respectively, the top-level entities of relations, functions, and individuals. OPTION C seems to introduce redundant distinctions Global, Local, Literal that are already in the rif:type attribute.
Sandro: Global, local, literal are only syntactic sugar for <const type="iri">
Michael: People will look at the presentation syntax
<Harold> While <Global>http://example.com/#r</Global> is indeed global, <Global>#r</Global> is not.
Prefer Opt A: 7; Prefer Opt C: 1.5;
<DaveReynolds> Harold: not true, a relative URI will be resolved relative to the xml:base
Sandro: Resolve RDF issue implicitly
Christian: What needs to be resolved for XML syntax?
Sandro: Const types are Curies, QNames, IRI?
Dave: Curies are not official
<Harold> http://www.w3.org/TR/curie/
Dave: types are all curies
Christian: but curries are not official
Michael: full URI
Mike: What about local?
Dave: it is rif:local
Christian: We have to specify meaning of curies
Dave: if we pick IRIs we are done
Curies prefer:0; full IRI prefer:9; curie+iri prefer:0; special syntax prefer:0/object: Jos
<sandro> PROPOSED: In the XML syntax, we'll use full IRIs (not qnames or curies) for Const types, etc. Of course, XML entities can be used.
Michael: QNames and IRIs are syntactically incompatible
<Harold> DaveR, but #r refers to the current document, say http://current.org, so is local to http://current.org: http://current.org#r.
<sandro> RESOLVED: In the XML syntax, we'll use full IRIs (not qnames or curies) for Const types, etc. Of course, XML entities can be used.
Christian: Issue on "Identify Dialects in the XML document"
<sandro> PROPOSED: dialect is identified by an IRI, in the document as an attribute rif:dialect on the root element
objection: Bob
Bob: Several different dialects for rule sets
Christian: Keep this question in draft 2
<sandro> PROPOSED: dialect is identified by an IRI, which appear in the document as an attribute rif:dialect on the root element (for WD2, until we figure out extensibility)
<sandro> PROPOSED: dialect-of-author is identified by an IRI, which appear in the document as an attribute rif:dialect on the root element (for WD2, until we figure out extensibility)
<sandro> PROPOSED: dialect-of-authoring is identified by an IRI, which appear in the document as an attribute rif:dialect on the root element (for WD2, until we figure out extensibility)
<sandro> RESOLVED: dialect-of-authoring is identified by an IRI, which appears in the document as an attribute rif:dialect on the root element (for WD2, until we figure out extensibility)
Christian: Issues from yesterday; syntaxt questions about triangle
... Shows summary from yesterday
... Need PS and XS
... Need mapping between XS and PS
Harold: Shows mapping table
<ChrisW> Christian dropped Gary
<GaryHallmark> but I bounced back
<sandro> Harold: okay to have table from PS to XML, in WD2
Michael: Make abstract syntax more abstract
<sandro> MK: I'd like to change the constant syntax in PR to Const(...) or something.
<sandro> DR: maybe uniterm goes to Uniterm(op arg arg arg)
Axel: Why do we want abstract syntax
Christian: Which options require many changes wrt draft?
Harold: option 1 requires most changes
... option 3 is easy
... table already exists
<GaryHallmark> harold, is your table online or in email?
Michael: two is easiest
... One and three are the same
... We want a structural model
... Structural model was shown by Christian for illustration
Christian: Do we want also diagrams
Sandro: Diagram is only editorial work
Christian: diagrams are for illustrations
Sandro; How is head distinguished from body in presentation syntax in the table
Jos: Can be figured out in document
<sandro> "Structural Model Diagram"
<sandro> Option 1: AS as interlingua beetween PS & XML -- no prefer
<sandro> Option 2: PS++ and Direct Mapping -- no prefer
Option 2: PS++ and direct Mapping - one
<sandro> Option 3: 1 _ diagreams
<sandro> Option 3: 1 + diagrams == 2 people prefer
Option 4: Opt 2 + diagram: 9 prefer
<sandro> Option 4. 2 + diagrams = 9 prefer
<sandro> PROPOSED: We will use Presentation Syntax, with minor changed, with a mapping table to the XML syntax, with structural model diagrams. In WD2 the diagrams are "for illustration".
<sandro> MK: Let's not mention normativity in this draft.
Sandro: Seperate diagrams from question about presentation syntax
<sandro> PROPOSED: We will use Presentation Syntax, with minor changes, with a mapping table to the XML syntax.
<sandro> RESOLVED: We will use Presentation Syntax, with minor changes, with a mapping table to the XML syntax.
<sandro> PROPOSED: BLD WD2 will have structural model diagrams (which look like UML).
<sandro> RESOLVED: BLD WD2 will have structural model diagrams (which look like UML).
Christian: Do we include ASN version in the document
Axel: Currently it is enough to have the structural model diagrams
<GaryHallmark> -1 for ASN: it's not a standard (is it?) and would be the 4th way to present the syntax
Harold: We just simplified things, so omitted Abstract EBNF (as the intermediate language in the translation table) as well as ASN06 and 07
<PaulaP> +1 to Gary's comment...and Axel's
<josb> +1
<sandro> PROPOSED: Remove ASN from BLD WD2.
Christian: Our diagrams are only UML like but not really correct UML
Harold: ASN is not expressive enough
... that was the reason for introducing AEBNF
Dave: Our ambition is to have a clear UML meta model in WD2
Christian: We currently only have illustrative diagram
... currentl diagram is not a meta model
... We must be very careful in the wording in the document
Chris: We use UML
... not MOF
<Harold> The current cautionary note is "The above abstract syntax can be illustrated with a UML diagram, as shown below."
<sandro> Christian: Large label, "THIS IS UML NOT MOF."
Dave: Diagram is not equivalent to the syntax
Christian: Does somebody want to have ASN as well?
Bob: It is confusing to have all these representations
Dave: +1 for Axel and Bob
<sandro> RESOLVED: Remove ASN from BLD WD2.
<ChrisW> scribe: Michael Kifer
<ChrisW> scribenick: MichaelKifer
discussion of structural model of rules
<sandro> PROPOSED: change structural model so that Forall, Implies, and Atomic are three parallel subclasses of Rule.
<sandro> csma: to resolve issues about extensibility and ground facts. ground facts don't need to be in a forall.
csma re-proposed a UML diagram where ground clauses are not under Forall
<sandro> csma: simplifies BNF, too.
Also proposes to hang metadata off of Rule
<sandro> PROPOSED: For WD2, change structural model so that Forall, Implies, and Atomic are three parallel subclasses of Rule (shown on Christian;s diagram labeled "BLD Rule: alternative")
<Harold> PROPOSED: For WD2, change structural model so that Forall, Implies, and Atomic are three parallel subclasses of RULE (shown on Christian;s diagram labeled "BLD Rule: alternative")
<sandro> Prefers current SM - 0
<sandro> prefers suggests SM - 8
<GaryHallmark> the proposed change allows forall(forall(...))
<ChrisW> yes
<sandro> RESOLVED: For WD2, change structural model so that Forall, Implies, and Atomic are three parallel subclasses of RULE (as shown on Christian;s diagram labeled "BLD Rule: alternative")
<ChrisW> ACTION: Christian to update diagram in BLD draft [recorded in http://www.w3.org/2007/09/28-rif-minutes.html#action03]
<rifbot> Created ACTION-355 - Update diagram in BLD draft [on Christian de Sainte Marie - due 2007-10-05].
<sandro> OCT 12 -- Frozen ED of WD2
<sandro> OCT 12 -- Reviews
<sandro> OCT 26 -- Freeze
<GaryHallmark> gotta run, folks. nice job tying up the XML syntax issues. "see" you Tuesday.
<DaveReynolds> ScribeNick: DaveReynolds
<scribe> Scribe: Dave Reynolds
Discussion on newer primitive types in the current BLD draft that received some comments
ChrisW: shows slide of these - rif:local, rif:text, rdf:XMLiteral
Michael: rif:local is constant which is local to a rule set
... in current draft no distinction to rif:iri because don't have modules, but once have modules the difference will be clearer
ChrisW: what is rif:text?
Jos: it is a literal we proposed to be equivalent to plain literals with language types in RDF, currently only in RDF section but will be added to the main text for next WD
ChrisW: what about rdf:XMLLiteral?
Michael: just a small fix was needed in text, done
csma: what are the consequences of this, is it an implementation burden?
[Discussion on this - if you want an xml literal you need something like this, we are just reusing the RDF approach]
csma: closing data for room block booking for F2F8 is Oct 3
ChrisW: if in doubt, book it
... what about F2F9
Paris and Ireland mentioned as possibilities
It will depend on the dates and the dates depend on the future of the WG, probably early 2008 (around Feb)
ChrisW: WG is chartered to end of Nov, what happens after that..
... Possibilities (1) we ask W3C for an extension
csma: for what puprose and for how long?
Phases: WD, Last Call WD (4-12 weeks), Candidate Rec (CR = call for implementations, time depends on implementations), Proposed Rec (PR = W3C member orgs vote on it, largely pro forma, 4-6 weeks), Rec
ChrisW: Possibilities are ...
(1) terminate
(2) extend (n months)
(3) recharter
Sandro: termination is the default
... extension formally is at the discussion of the director but in practice Sandro asks the management committee which might lead to dialogue with us
... recharter requires going back out to the whole membership
No one argued for option other than (2) extend
ChrisW: to do that we need reasons and new schedule and reasons we think we can make it
csma: preference to ask for short extension (6m?) to aim to enter LC for BLD
... then will know whether we are going somewhere or not and will then be able to put together realistic schedule for PRD and extension mechanism etc
... then we either ask for second extension to finish BLD or longer one to cover PRD etc
Sandro: we give ourselves 6m to figure whether we can indeed tie business rules in
... so we need enough work done on PRD to know how they fit together and what that means, they don't need to be at public working draft
... one of the requirements for RIF is extensibility and don't want to go to last call untill have some answer to that
ChrisW: is 6m to do this is feasible?
Jos: charter also asks us to take OWL compatiblity seriously, and we would need to get concensus on that
Michael: also wants module mechanism
So list of requirements for getting BLD to LC are:
- proven extensibility
- OWL compatibility
- Modules
- builtins
- conformance
- engine definition (i.e. need entailment definition and incusion/modules but NOT query language or API)
- UCR should go to LC
- test cases would be good
- extensibility mechanism rather than "proven" extensibility!
Sandro: charter defines what we have to say about extensibility, if someone asks how we would go a given extension we have to either indicate how to do this or why the extension is not necessary for rule interchange
Axel: arch and extensility sort of the same thing, so we need another one or two examples and how relates to BLD
csma: hence PRD
Sandro: would like so see Datalog and FO dialects
... as examples of how to do extensibility
Michael:
Axel agrees to take on some of Arch edit with Sandro but wants to talk about timeline
ChrisW: editor's draft by next F2F?
Axel: if we can just trash the unnecessary bits and do the minimum then OK
csma: if we work on that then we'll have a better idea of the timescale for extensibility which is why a short 6m extension is sufficient to derisk the following schedule
ChrisW: adds "- Arch to LC" to the list of goals of the extension
... concerned about having a whole other dialect on the path to extensibility, doesn't want that on critical path to BLD LC, a sufficient Arch LC would be good enough
Sandro: strawman/example dialects sufficient, not standard dialect
cmsa: in the first stage the PRD would be just a strawman/example
<sandro> I want Datalog and FOL as example/straw dialects. PRD can be an example dialect OR a standard.
ChrisW: be clear in minutes - that we agree that a second standard dialect is not a necessary requirement for meeting the extensibility requirement from charter
<sandro> Chris: I want it recorded that we agree that The Extensibility requirement from the charter is NOT contingent on having a second (real) dialect.
What about "OWL compatibility"?
csma: not necessary part of BLD can be separate document on different timescale
Sandro: can't get out of CR without that doc, it would be a mistake to have that lag too much behind
Jos: would actually prefer the OWL compatibility (and RDF) in a separate document
ChrisW: is that other document another dialect? the combination part extends the semantics, isn't that another dialect?
Michael: less clear now on exactly what the combination semantics implies
Discussion on whether need the OWL compatibility doc before taking BLD to last call
<sandro> PROPOSED: The OWL Compatibility text will proceed to Last Call in sync with BLD.
<sandro> RESOLVED: The OWL Compatibility text will proceed to Last Call in sync with BLD.
<sandro> PROPOSED: No Modules! (mk out of room)
builtins - yes we need these
conformance? - yes need this
entailment? yes but we already have that
test cases?
ChrisW: would need someone to act as test case maintainer
Sandro: the test cases need not be a big deal
ChrisW: the test cases need to be correlated with the issues in the design, especially on a language with inferential capability
Adrian, Sandro volunteered to help with test cases (Sandro thought Gary might also have an interest in helping)
csma: data type extensibility is an example of thing that would need test cases
modules? just missing and intend to add or is it critical path for BLD?
Michael: needed whenever with have some form of include, what OWL did is not good enough for rules because rules interfere with each other a lot
Paula: offers to propose module system for BLD
Michael: there are already some such proposals in existence (e.g. from Rome(?) group)
... well more important that some features we already have
Sandro: lists are also mentioned in the charter
ChrisW: so is a 6m extension to get to start of LC the right thing to ask for
DaveR: what about extension to end of LC so can get external feedback?
Sandro: sees extension more about internal, can we get to agreement
... a test is how much of WG can come to F2F and do the work through this extension
<sandro> sense of group (unanamous) ask for 6 months extension..... (with some fuzziness :-) some sense of maybe ask for more.
strawpoll on 6m extension? no one opposed, almost everyone in favour
<sandro> scribeNick: StellaMitchell
jos: I have 2 use cases in mind, re: rdf compatibility
... 1. RIF rules + RDF data
2. RIF rules with RDFS data model
jos: (giving example, rdf graph that shows that rdf data and rdfs data model are similar)
... RDF semantics - semantics is defined in a similar way to RIF
... : RDF semantics defines 4 normative entailment regimes
... I will describe 2 of them: simple and RDFS
... simple doesn't take into account any special vocabulary
... rdfs takes into account rdfs vocabulary
... (describing blank nodes)
... so, the question is, given these entailments, how do we address the 2 use cases?
... at syntactic level, you have a RIF ruleset R and an RDF graph S, and the combination <R,C>
... then we have to define at the semantic level how those 2 things interact
... example: if x is student then x is poor
... need to have a way to relate above rule to an RDF graph
... at syntactic level, easy mapping between RDF triples and RIF frames
... so writing above example as: isPoor(?x) :- x[rdf:type --> student]
... but need to be precise for the specification
... so, interpret the RIF ruleset R with RIF interpretation, and the RDF graph S with the RDF interpretation
... and add conditions on the interpreations
... if you use rdfs data in your rules, I think you must use the rdfs semantics
... now that we have semantics, we can specify entailment in the usual way through model inclusion
... and we can define it for each of the RDF types of entailment
... the receiver of the RIF rules that refer to an RDFS data model, you want to be able to process the rules (querying, entailment checking)
... and in order to do that, you must have an embedding so that you can check entailment with your rule engine
... so, we need to be able to check for satisfiability
... I defined a translation function to allow that to be done
chrisw: in the example rule, there is no entailment on the graph?
jos: right
michaelk: I now understand what Jos wants to do now, and I now
... believe that combined semantics is required and the embedding is not
... I now understand: there is a rule lang that works with rdf data, and another rule lang with diff syntax and also works with rdf data
... so, I think we need a dialect to do this
... an RDF dialect
... to specify the dialect, we need to define syntax and semantics
... note that the data is not exchanged via RIF; it has its own exchange language
axel: I think RDF data should stay in it's RDF form and not be embedded
MK: right
... so, in conclusion, I think we do not need the embedding
... (just the combined semantics)
... (I am confused about it - about why we mignt need embedding)
chrisw: what if we have a ground entailment?
... what if you have non-ground entailment that cannot be expressed in RDF?
... it goes into the combination
... (entailments that cannot be encoded in a graph)
... what about ground frames in ruleset?
... what is the correspondence between that and RDF graph?
jos: it would be in entailed graph and entailed condition also
daver: I want to record that we need a way to treat RDF as data