See also: IRC log
<PaulVincent> scribenick PaulVincent
<PaulVincent> Christian: will decide today on breakout topics eg implementation...
<PaulVincent> Chris: session on Extensibility
<PaulVincent> scribenick: PaulVincent
Reviewing Sandro's Extensibility_Design_Choices doc (all definitions
quoted in the minutes below are from this document)
Definitions: what is a RIF Document?
"A RIF Document is an XML document with a root element called "Document" in the RIF namespace (http://www.w3.org/2007/rif#). In general, RIF documents are expected to convey machine-processible rules, data for use with rules, and metadata about rules."
Paul: does this imply all data in a RIF doc?
Jos: RIF doc may not be XML?
Sandro: that is the current intent: RIF is an XML doc
Christian: RIF may not contain data for use in rules
... withdraws comment
<sandro> PROPOSED: accept definition of RIF Document as in http://www.w3.org/2005/rules/wg/wiki/Arch/Extensibility_Design_Choices?action=recall&rev=35
Chris: proposes RIF Document definition is set once here as normative
Christian: if this is a final definition then need more defining eg on data containment
Axel: object to definition on root element as RIF:Document
<Harold> What about: In general, RIF documents are expected to convey machine-processible rules, facts for use with rules, and metadata about rules.
<sandro> PROPOSAL WITHDRAWN
<sandro> Chris: defn okay -- nothing but nit picking complaints
Chris: retracts enforcement of never-adjust-this definition
<sandro> Sandro: I do intend "RIF Document" to imply they are all XML documents
<sandro> Chris: The other issue was data, facts, and making it lower priority (ie at end of list with weasel words)
Harold: would prefer facts rather than data (in RIF doc
definition) as knowledge = rules + facts
"A RIF System is anything which
might produce or consume a RIF Document.
Typical RIF systems include rule authoring tools and rule engines. These systems may consist
of a non-RIF subsystem and a RIF translation
subsystem; taken as a whole, they form a RIF system."
<sandro> Sandro: Are "RIF Consumer" and "RIF Producer" good?
<sandro> everyone happy
<sandro> re RIF Dialect -- Axel -- Dialect may have more than XML.
"A RIF Dialect is an XML language
for RIF Documents. Each RIF Dialect
defines semantics for the set of RIF Documents which conform to its syntax definition. Dialects
may overlap other dialects; that is,
a given document may be an expression in multiple dialects at the same time. "
Axel: objects to RIF Dialect being an XML language
<AxelPolleres> On http://www.w3.org/2005/rules/wg/wiki/AbstractModel I proposed the following notion...
<AxelPolleres> (which is probably also not the last word, but some things might be worthwhile):
<AxelPolleres> # a dialect MUST restricts/define which parts of the abstract model you are allowed to use in its instance rulesets and how.
<AxelPolleres> # a dialect MUST assign a semantics to this restricted part (model-theoretic, proof-theoretic, operational in that order of preference)
<AxelPolleres> # a dialect MAY assign "roundtrippable" own syntaxes (for instance, BLD defines a represenation syntax as well as an XML syntax) and even define the semantics in terms of one of those special syntaxes (for instance BLD's semantics is defined in terms of its representation syntax).
<sandro> Bob: usually assumes you can write syntactically valid programs without them being meaningful.
<sandro> Sandro: I specifically mean to rule that out.
<Harold> What about: A RIF Dialect is a specification of a (usually infinite) set of RIF Documents.
<AxelPolleres> what is missing is probably: # MUST defne an XML Language for RIF Documents
<sandro> Bob: Then syntax must be clear as going MORE DETAILED than in Schema.
<sandro> Gary: cf Signatures....
Christian: dialect is more than a schema
... dialect has a normative specification outside of the schema
<sandro> Axel reads what he put on IRC.
Axel: suggests bullet list for definition
<sandro> Sandro: Let' leave dialect not well defined and move on.
Chris: move onto definition of Language Conflict
"A Language Conflict occurs when multiple dialects specify different meanings for the same document. That is, if there can exist a RIF Document which syntatically conforms to two dialects, and a system can be conformant to one of the dialects without also being conformant to the other, then there is a language conflict between the dialects. "
Harold: can only have inclusion hierarchy: multiple semantics is an issue
Christian: need to define language conflict to know what we need to avoid
<sandro> MK: the def of Lang Conflct doesn't need to go into Spec -- that's for us.
Sandro: this may be a concept for dialect designers
Michael: we should design to avoid this
<sandro> csma: We seem to agree what is a language conflict, and that we don't want them.
Chris: RIF Extension
"A RIF Extension is a set of changes to one dialect (the "base" dialect) which produce another dialect (the "extended" dialect), where the extended dialect is a superset of the base dialect. "
<sandro> Axel: Superset in the sense that every document in the extended dialect is a document in the base dialect.
<sandro> Jos: superset is too restrictive.
<sandro> csma: but that's what extension means.
Jos: removing from "where" to avoid "superset" will be more general
Chris: RIF Profile is the complement of RIF Extension
"A RIF Profile is the complement of a RIF Extension; it is a set of changes to one dialect (the "base" dialect) which produce another dialect (the "profile" dialect), where the profile dialect is a subset of the base dialect."
Sandro: Profile is a general term for a standard subset
Jos: this is already a design choice (Extension and Profile)
<sandro> Jos: These definitions reflect reflect some design choices -- they preclude naming dialects
<sandro> Sandro: true
Jos: removing subset/superset makes extension=profile
Christian: can extend definition to be extension = dialect that covers more rule types than the parent (etc)
<sandro> Sandro: rif change, modification, delta, .....
Chris: ... but extension could also modify definition of ruleset etc
Christian: RIF extension can also process the parent's rules
<sandro> csma: we need to keep in mind that "RIF Extension" as written here is a specifc kind of thing, and there is a more general notion.
Chris: need another term for a delta / derivative that is not an extension / profile
<sandro> "RIF Functionality Extension" vs "RIF Pure Syntactic Superset Extension"
Sandro: RIF syntactic extension and functional extension?
Michael: Also consider an "invisible extension" ... so we need to define the extensions more specifically
Jos: invisible extensions that are just syntactic then this is not a RIF extension
<sandro> Jos: this definition means "invisible extension" is not an extension.
<sandro> Sandro: true.
<sandro> Chris: Maybe metadata doesn't count as part of the syntax....?
Chris: need to define a more general notion of RIF
... Backward and Forward Compatibility
"A system is Backward Compatible if it accepts old versions of its input language. All systems are backward compatible for languages which change only by incorporating extensions (that is, by growning). In a large, decentralized system (like the Web), backward compatibility is extremly important because new system will almost certainly have to read old-version data (either old documents, or documents recently written by old software)."
"A system is Forward Compatible if it behaves well when given input in future or unknown languages. In a large, decentralized system (like the Web), if the systems are not all forward compatible, new language versions are extremely difficult to deploy. Systems which are not forward compatible will behave badly when they encounter new-version data, so the users of these systems will tend to push back on the people trying to publish the new-version data. If a large enough fraction of the user base is using such systems, the push back becomes too great and migration to new versions is prevented. In small, controlled environments, the software for all the users can be upgraded at once, but that is not practical on the Web."
<sandro> Chris: I understand BC, but it sounds like there is wiggle room around metadata, eg language identifier....
Sandro: example: IE identifies itself as Mozilla as this was meant to be metadata but is now used as an executable interpretation...
<AxelPolleres> I personally don't really like dialect identifiers... so far, any convincing argument for them?
Sandro: Metadata compatibility is important (Chris: some noncompatible metadata changes may not prevent executable backward compatibility)
Christian: "future or unknown languages" term means?
Sandro: this is simply a problem definition, not a solution
<AxelPolleres> What I wanted to say is that Fwd-compatibility, if desired, already *fixes* the fallback mechanism in some sense.
"A Fallback mechanism provides forward compatibility by defining a transformation by which any RIF document in an unknown (or simply unimplemented) dialect can be converted into a RIF document in an implemented dialect. In many cases, fallback transformations will have to be defined to be lossy (changing the semantics of the document). Fallback mechanisms can be simple, like saying that certain kinds of unrecognized language constructs are to be ignored (as in CSS), or they can be complex, invoking a Turing complete processor (as in XForms-Tiny)."
Sandro: allows for graceful behavior - predictable degradation
Jos: why should fallback imply convergence eg rather than ignore some aspect
<AxelPolleres> examples for Fallback:
<AxelPolleres> - refuse ruleset
<AxelPolleres> - ignore rules
<AxelPolleres> - ignore rule parts
Michael: this is an issue, not a solution
Axel: is "ignore" a transformation?
<AxelPolleres> note there is also "semantic fallbacks" probably. (think of strict vs. loose language layering (in Jos' sense))
<sandro> Jos: switching from "transformation" to "mapping" helps.
<Harold> Issue: If the receiver just omits what they can't understand, the sender won't know how much was understood. So, the receiver need to inform the sender about what they omitted.
<AdrianP> Define default semantics as a fallback mechanism
Sandro: a single dialect extension may have multiple
fallbacks with multiple impacts
"Impact is information about the type and degree of change performed by a fallback transformation. For instance, a fallback transformation which affects performance might be handled differently from one which will cause different results to be produced. This difference is considered impact information. "
<AxelPolleres> Examples of impact might be:
<AxelPolleres> - soundness lost
<AxelPolleres> - completeness lost
Gary: Example - bad element tree being pruned: ie could remove part or all of a rule
<AxelPolleres> sounds kind of like "cautious" and "brave" fallbacks.
<sandro> Gary: prune at AND and you get false negatives; prune at RULE and you get fewer results --- user needs to choose.
Chris: highlights of extensions
... user extensions vs official extensions
"Extensible systems may support User Extensions (Vendor Extensions), Official Extensions or both. A user extension is one which can be defined and widely (and legitimately) deployed without coordinating with a central authority (such as W3C or IANA). Official extensions are those produced under the auspices of the organization which which produced the base dialect (in this case W3C). Some people consider user extensibility to be required for a system to truly be extensible. The RIF Charter extensibility requirement concerns user extensions."
Christian: user extensions for own fancy features via an extension framework - this is a strong motivation for adoption of extensibility
<sandro> csma: Big Goal: to allow users to deploy extensiion which eventually turn into official extensions.
Christian: examples may be vendor extensions, which can then be brought into an official extension
<AxelPolleres> Do we want to go down to how a certificate for endorsement of a dialect needs to look like?
<Harold> How to avoid that a vendor comes up with their fancy 'user' extension to differentiate themselves from other vendors.
Christian: will say 2nd example after the break...
BREAK to 10.35
<Harold> ... We could encourage vendors to collaborate on joint 'usergroup' extensions, so chances would go up for their extensions to become official.
<ChrisW> Scribe: MichaelKifer
discussion of invisible extensions
"An Invisible Extension defines a
dialect which has exactly the same
syntax as some other dialect but different semantics. This is sometimes desirable when the
different semantics are related in a practical
and useful way, such as reflecting the different capabilities of competing implementation
technologies. Deployment, testing,
and the definition of conformance for invisible extensions require out-of-band information,
which may be problematic. For example,
there is a subset of OWL-Full which has the same syntax as OWL-DL, but which has more
entailments (ie different semantics). This subset of OWL-Full is an invisible extension of
OWL-DL; its presence (and
thus the different intended semantics) cannot be determined by inspection and must be conveyed
out-of-band in any applications where the
semantic difference might matter."
csma: clarify the diff betw invisible extensions and language conflicts
sandro: invisible extension is a "harmless" language conflict
<sandro> *might* sometimes be harmless.
<sandro> Jos: better example of invisible extension is RDF and OWL-Full. Same syntax, very very different semantics.
<sandro> Sandro: Yes, but.... some caveats maybe.
mk: dont want language conflicts, but the notion of invisible extension is useful for specifying fallbacks and impact factors.
sandro,csma: want to avoid invisible extensions
scribe: as well as language conflicts
<sandro> Chris: There is an intuitive notion of Invisible Extension that makes it different from Language Conflicts in general....
<sandro> Sandro: Yes
<AxelPolleres> How about, "Strictly semantically layered extension" and "loosely layered semantically layered" semantics.
examples of invisible extensions: OWL-DL->OWL-Full, Well-formed, stable negation vs stratified negation
<ChrisW> seemed like general agreement that invisible extensions and language conflicts are the same and undesirable
<Harold> Since XML can express things with elements or attributes, we should use one element, e.g. Naf, with an attribute, e.g. flavor, which could distinguish stable, well-founded, etc.
<sandro> Sandro: An "invisible extension" would be "naf" and you have to say out of band which kind of NAF it is.
<Harold> So, <Naf flavor="stable"> vs. <Naf flavor="well-founded">
<AxelPolleres> ChrisW, they are NOT the same: invisible extensions are a special case of conflict!
<Harold> where one could be picked as the default.
<josb> "An invisible extension defines a dialect which is a superset of the base dialect, but which defines a different semantics for documents in the base dialect."
sandro: motivating example for user-defined extension
... what's the mechanism for granting permissions to define a dialect?
Harold: namespace change is not a problem
<Harold> because it also occurs for RIF's own versions.
csma: if u want to become a standard, use RIF namespace.
sandro: may not know if something will become a standard
at the beginning
... another way is to rewrite vendor NS into a RIF NS automatically
<Harold> Developers of user dialects should be strongly encouraged to reuse as many as possible of existing (official) standards when they look for a basis to define their own extension dialects.
sandro: how can we ensure that different groups developing different dialects don't step on each other
<AxelPolleres> +1 we need some "principle of maximum reuse"
csma: pro for having a central authority: there is some quality control
<Harold> Re 2.1.2: What about a much less expensive light-weight control.
sandro: W3C doesn't want to be a central authority for
every possible extension. This position has led OASIS to take over some
of the extensions.
... of XML
csma: create a RIF Consortium
sandro: central repository of namespaces has a problem in case of IP and patent enforcement attempts
<Harold> Maybe, by analogy to Incubator Groups, W3C needs a notion of 'Outcubator Groups' which maintain further development of specs after a WG ended.
<sandro> csma: we'll have to decide soon whether BLD and PRD use the same namespace
<AxelPolleres> solution: common abstract model, common namespaces for overlapping constructs :-)
csma: how do we manage overlap between dialects? for ex: BLD and PRD are not extensions of each other, but they share the condition sublanguage. What namespace for that sublanguage?
<sandro> sandro: if we think of BLD lists as an extension, is there some reason to put them in a different namespace.
gary: maybe just use the same namespace for everything?
csma: but how do we achieve this at the technical level?
axel: another way is to split off abstract model and dialects, e.g. CONDITION is an abstract model construct, it is not specific to a dialect
<Harold> The namespace http://www.w3.org/2007/rif# should contain at least http://www.w3.org/2005/rules/wg/wiki/Core/Conditions. A new namespace http://www.w3.org/2007/rif/horn# could be created for http://www.w3.org/2005/rules/wg/wiki/Core/Rules. BLD would then become an extension of Conditions by Horn rules.
<sandro> PROPOSED: RIF-WG will only use its one namespace, but to allow user extension to use other namespaces.
csma: what if the same document is in both dialects (eg, a subset of PRD and BLD)? Then u don't want the same constructs (eg negation) to be in different namespaces.
<sandro> PROPOSED: All official extensions will use the main RIF namespace, but we will support user extensions using other namespaces.
<AxelPolleres> Well, we would be getting close to a Core here again, harold, don' we?
<sandro> PROPOSED: All official extensions will use the main RIF namespace, but we will support user extensions using other namespaces.
<sandro> PROPOSED: All official extensions will use the main RIF namespace, and we will support user extensions using other namespaces.
<sandro> PROPOSED: All official (ie standard) dialects will use the main RIF namespace. We will support user extensions using other namespaces.
<sandro> Harold: what about subspaces?
<sandro> Sandro: No, really the same namespace string.
<AxelPolleres> This fits very well with the common abstract model idea... btw., I like it.
<sandro> RESOLVED: All official (ie standard) dialects will use the main RIF namespace. We will support user extensions using other namespaces.
<sandro> csma: if this leads to serious design difficulties, we may to re-open this, of course.
csma: this resolution may cause design difficulties. if this occurs then we'll dissolve or modify the resolution
<sandro> Do we ever allow invisible extensions? => not really resolved yet
csma/sandro: issue: do we allow invisible extensions?
mk: unclear what "allow" means
<sandro> How do you know when extensions are compatible? => no idea yet.
issue: how do we know if extensions are compatible?
csma: probably we don't care
<sandro> "Do people ever need" .... component library, mk: difficult for 6months times. => No criticial impact here now.
<Harold> An extension should always start from the largest base dialect(s) that will be semantically contained in the newly defined dialect.
issue: should we allow flags at the document root to modify the meaning of syntactic constructs (eg, to say whether negation is a WFS-NAF or ASP-NAF or ...)
sandro: table this for the moment
<AxelPolleres> I think further, we could probably not get anything more than a "principle of maximum reuse" and something like defining BLD and PRD as core in the following sense. Proposal:
<AxelPolleres> Other dialects should reuse BLD and PRD wherever possible. Other dialects MUST agree with the semantics of BLD and PRD on the parts (of the abstract model) they share with BLD and PRD.
<Harold> Starting from the 'largest' base dialect(s) will exclude starting from the 'null' dialect except when defining a totally different language (unrelated to the rest of RIF).
csma: is it possible to tell when ASP and WFS agree?
<sandro> Merging: wfnaf in one file and smnaf in the other, and you merge them..... document-level flags wont allow that.
mk: no. it's undecidable, but some sufficient conditions (stratification at the predicate level) exsist
<AxelPolleres> -1 to document level flg for the moment, not convinced yet. the smsnaf vs wfsnaf issue could be solved with different identifiers for the different nafs.
<Harold> 'Document-level flags' correspond to the XML attributes I mentioned earlier: Eg. a 'flavor' attribute for Naf, which distinguishes well-founded, ... semantics.
<sandroPost> scribeNick: AdrianP
csma: document publication plan
... how many documents; which ones; why, what dependencies, etc
<sandro> mk: 1. arch with fallback + extesnibility stuff 2. two for logic
michael: ideally architecture document (fallback,
extensibility), logical framework, production rule framework
... Framework for BLD and PRD
<Harold> shuffled material from BLD.
michael: seperate documents, e.g. ARCH document, CORE framework, BLD
<sandro> csma: rule of thumb -- different audiences == different documents.
Michael: we would have very large documents otherwise
... signature, semantics etc are currently in BLD and should be moved
csma: compatibility of dialects with OWL, RDF,
compatibility of PRD to XML schema
... shall this be described in an extra document?
chris: + different framework for PRD?
chrisw: Arch could be split into different documents?
michael: CORE is postponed after PRD
csma: do we need a core for different dialects
chris: interchange and overlap covered by Extensibility document?
axel: principle of extensibility needs to be written in Extensibility document
<AxelPolleres> As proposed earlier:
<AxelPolleres> " Other dialects should reuse BLD and PRD wherever possible. Other dialects MUST agree with the semantics of BLD and PRD on the parts (of the abstract model) they share with BLD and PRD."
sandro: as a user you are interested in the core (overlap)
... this overlap should be extracted and written down
chris: Is Core is an instantiation of guidance how to interchange two dialects
csma: Instead of having a Core could it be a profile of PRD and BLD?
<Harold> The 'Core' overlap (based on the Condition Language) of BLD and PRD consists of the Pure Production Rules we had discussed early on and its extensions (e.g., by Naf, Bagof, ...).
Sandro: intersections of dialects should be documented
<AxelPolleres> chrisW said: Extensibility should define how to specify interchange between two non-subsuming dialects. (Q: Do you mean by defining fallbacks? in that case agreed.)
<sandro> If there is a useful overlap, then it should be documented.
Jos: Extensibility talks about extension of XML syntax
... Framework talks about semantic extensions
Axel: Framework currently defines general notions of semantics, signatures
Jos: purpose of framework?
csma: example: PRD reused conditions of BLD, i.e. PRD
points to BLD
... so it might make sense to take it out of BLD
jos: e.g. signature are not used
michael: signatures set the framework for extensions
... Framework creates the general framework how to create dialects by specialising
... Framework can evolve
... Framework is about logical extensibility
<AxelPolleres> Suggestion for what the "Framework" is:
<AxelPolleres> 1. Each RIF dialect MUST define a semantics (model-theoretic, proof-theoretic, operational in that order of preference).
<AxelPolleres> 2. Principle of maximum reuse: Other dialects should reuse RIF endorsed dialects (currently BLD and PRD) wherever possible.
<AxelPolleres> 3. Other dialects MUST agree with the semantics of RIF endorsed dialects (currently BLD and PRD) on the parts (of the abstract model) they share with BLD and PRD.
sandro: fallback mechanism is standard for RIF
chris: Extensibility and Framework need to be understand by dialect designer
<sandro> every fallback "programming language" has to be implement in every RIF consumer.
<AxelPolleres> "The RIF Semantics Framework provides means to define semantics for logical dialects and BLD is an example which uses this Semantics Framework. This does not preclude dialects to define their own semantics in a different way. However, reusing the Semantics Framework may ease the task of proving that a dialect fulfills (3.) above."
<GaryHallmark> Scribe: GaryHallmark
<scribe> ScribeNick: GaryHallmark
not sure about the agenda item, but we are discussing public comments
dicussing comments from Peter Patel-Schneider
why 3 different kinds of atomic formulae?
this will be addressed in the semantic web compatibility doc
why is new treatment of data values needed?
josb: why different from rdf and owl
... difference is rdf/owl use data maps, but rif has fixed list
... rif does not use data mapping
michael: leaving data types open could be dangerous for rif
only 1 or 2 attendees claim to understand this distinction
chrisw: should this be an issue - fixed v. open data types
michael: how can RIF semantics handle open data types negotiated out of band?
josb: entailment checking would use out of band info, too
chrisw: need an action to determine difference in type handling and justify if there is a difference
<sandro> ACTION: jdebruij to explain in writing the difference in 'treatment of data types' mentioned in PFPS's comment [recorded in http://www.w3.org/2007/11/05-rif-minutes.html#action03]
<rifbot> Created ACTION-362 - Explain in writing the difference in \'treatment of data types\' mentioned in PFPS\'s comment [on Jos de Bruijn - due 2007-11-12].
why is there a symbol space for IRI identifiers?
<sandro> MK; to increase uniformity.
<sandro> ACTION: kifer to make a wiki page for replying to PFPS and start drafting reply, including explain why the symbol space for IRIs. [recorded in http://www.w3.org/2007/11/05-rif-minutes.html#action04]
<rifbot> Created ACTION-363 - Make a wiki page for replying to PFPS and start drafting reply, including explain why the symbol space for IRIs. [on Michael Kifer - due 2007-11-12].
treatment of slotted formulae is "unusual"
chrisw: ask Peter if it is a problem
condition language is very complex
josb: 3 frame formulas, slotted predicates, etc.
harold: it's not "complex", it's "rich"!
sandro: could be simpler
chrisw: some of these comments don't need a response
why worry about interpretations where IP is not a subset of IR?
<sandro> ACTION: jdebruij to respond to '"Why worry about interpretations where IP is not a subset of IR", explaing how keeping the option of RDF Entailment open. [recorded in http://www.w3.org/2007/11/05-rif-minutes.html#action06]
<rifbot> Created ACTION-364 - Respond to \'\"Why worry about interpretations where IP is not a subset of IR\", explaing how keeping the option of RDF Entailment open. [on Jos de Bruijn - due 2007-11-12].
<sandro> Jos: you can no longer have ill-types literals in RIF.
<sandro> ACTION: jdebruij to draft reply to PFPS about il-typed-literals and make sure Chris likes it [recorded in http://www.w3.org/2007/11/05-rif-minutes.html#action07]
<rifbot> Created ACTION-365 - Draft reply to PFPS about il-typed-literals and make sure Chris likes it [on Jos de Bruijn - due 2007-11-12].
josb: latest draft ties rdf:type and rdfs:subClassOf to # and ##
no actions on RIF-OWL compatibility
why are xsd:date, boolean, float excluded but xsd:int are required? Why is xsd:integer the only derived datatype?
csma: not really done on purpose
what is the arity of #Imadethisup
discuss implementation plans
who plans to implement bld?
axel: will not implement function symbols
<sandro> Kifer, Adrian, Harold, Igor, Axel--partial, Sandro
<sandro> kifer: in and out translators for XML, ... I don't know, toward end of 2008. If only presentation syntax then flora-2 already implements all of this.
<sandro> sandro: i certainly plan to implement translators between XML and presentation syntax, .... but PS isn't real.
<sandro> kifer: I doubt anyone can really implement equality.
<sandro> csma: implementation means that you can produce and consume RIF BLD documents.
<sandro> kifer: some substitutions are very expensive to do.
sandro: python translator for N3 and prolog
<AxelPolleres> axel: I would implement what can be handled by our engine, ie. datalog, w/o equality, but I could use RDF as data and would try to look into NAF extensions based on that.
adrian: translate to/from prova (an iso prolog language)
<sandro> 2-3 months
<sandro> prova == prolog + java
<sandro> adirian: I'd use XSLT
<sandro> Harold: OO-jDREW
<sandro> Harold: I'd also use XSLT
<sandro> Harold: estimate completeion end of 1Q08
adrian: would wait for stable bld spec
<sandro> Mike: Did SWRL to BLD, XSLT.
<mdean> next step: validate output against just-published XSD
<sandro> Igor: we're mostly interested in producing RIF rules, from our machine learning systems. we need builtins, lists, NAF, ... first.
igor: leverage another rif consumer to execute what we produce
<sandro> Igor: we'd want to use consumer, based on Flora or Prolog. It should take a couple months, after BLD is really fixed -- not at this stage.
<sandro> Axel: I want a hook in the language for referring to RDF data sets.... I want something quick based on the presentation syntax.
<sandro> Axel: ~2 months, when we have RDF reference mechanism.
<sandro> Chris: implementor's breakout tomorrow....
<sandro> PaulVincent, Gary, Stella, Bob === waiting for PRD
<sandro> Jos - academic, at the moment.
<sandro> ilog == prd as well.
<sandroPost> scribeNick: Harold
... walk-thru explaining assumptions etc.
... Formal description based on Claude Kirchner et al.'s rewriting approach.
(from project MANIFICIO)
MichaelK: You have semantics in two places, one not used.
csma: maybe one to be removed.
Gary: Hard to discuss semantics before having any syntax.
csma: Occasionally useful.
Gary: OK, on the level of deciding model-theory, operational, etc. semantics.
csma: Removed pattern language section.
... Reuses condition language.
Jos: Thought you dont support function symbols?
... Actions in the 'head' (then-part) of rules. But action lang. extends condition language.
csma: Two actions: Add/Remove a fact.
... Not an extension of Condition language, but new lang. on top of it.
... OK, but only first draft.
... Copied from BLD: 1.3.2 (Why is it a Web lang., ...)
... Diff from BLD: Structural diagrams and XML for syntax. No presentation syntax.
Gary: Why none?
csma: Not needed.
MichaelK: But it's on the first page.
Gary: PR vendors will want to see a presentation syntax. To discuss what a given snippet means.
csma: Starting from the botton.
Jos: Another use of pres. syn.: didactic, introductory reasons.
csma: Audience for PRD more developers than academics, so
more interested in XML.
... E.g. Mark Proctor said: "... just give me the XML syntax involved..."
... Took BNF syntax principles from WSDL.
... E.g. defined_element contains BNF (comment?)
... Condition lang. with a few modifications: simplifications such as removing some things.
... Classification only uses Membership. Frame only with one object, one slot (deal with the rest in the XML syntax as syntactic sugar).
Gary: ALso see it as too general in BLD?
Gary: Let's resist temptation to try in PRD to fix issues of BLD.
Gary: If you get rid of Uniterm then you dont have nested functions, which are not present in production rule systems.
Sandro: For calls you dont want to distinguish if they are builtins or user-defined.
<AxelPolleres> If we don't syntactically distinguish built-ins, I am a bit worried about extensibility, honestly.
MichaelK: builtins in both head and body?
<AxelPolleres> Why should a thing in one dialect be a logical function and in the other a builtin??? THat would be the result of not syntactivally distinguishing them, or no?
csma: Yes, but no problem since there are no function symbols.
<sandro> Not in one dialect vs another --- one *implementation* vs another.
<AxelPolleres> same with interpreted functions.
csma: Tried to be compliant with PRR.
<sandro> Like, append/3 can be a built in or a library function.
<AxelPolleres> or a logical function :-)
<sandro> library function == logical function, as I meant it.
csma: This community is more development oriented. That's why added more than absolutely necessary.
<AxelPolleres> ok, so, how to distinguish? each dialect needs to specify which are built-in (ie. fixed interpretation) and which are logical (ie. variable interpretation) functions/predicates?
csma: NonMonNot is neutral with respect to earlier discussion about negation.
<AxelPolleres> and obviously the symbol spaces need to be disjoint for those.
csma: TERM like in BLD -- could become a substitution
... Const copied BLD part about symb. spaces.
<sandro> In dialect1 append/3 is not built in, so if you want it, you must somehow cause its definitional as a logic function to be loaded. in dialect2, append/3 is built in. [I'm not saying this is absolutely the best way to do it, but it has some advantages.]
csma: Keep 'type=" ... IRI ..."
<AxelPolleres> "NonMonNot is neutral with respect to earlier discussion about negation." ... If we would have had (general) NAF in the condition language, would you have reused it?
<sandro> actually, this probably violates No-Language-Conflicts....
<sandro> this == my side conversation here about append/3.
<AxelPolleres> yes, that is what worries me, sandro.
csma: Even inlined examples need no pres. syntax: <Const type="SYMSPACE">LITERAL</Const>.
<sandro> Yeah, I think you're right, Axel.
csma: Different communities -- different ways to write rules.
Gary: Dont think this at all. Only want to see 'deltas' w.r.t. BLD, not need to learn pres. syn. from scratch.
csma: I thought people from ILOG, ORACLE, etc. will directly start to read PRD (dont need to read BLD documents).
<AxelPolleres> As for the nonmonnegation... I, from an abstractModel point of view, ask myself is NAF a subclass of NonMonNegation or the other way around, or are they completely unrelated?
<AxelPolleres> (conceptually, they are obviously related...)
Paul: Potential use case: could use logic or production rule approach.
Gary: Perahps it was a historical accident that business users chose prod. rules, not logic rules.
csma: Gary, I agree that BLD and PRD docs should LOOK the
... Would argue BLD should be restructured like this, by components (not as a whole), would make it easier for developers.
Gary: Better to be common than to be slightly better: Lets not try to do BLD changes in PRD.
csma: If it makes sense as now in PRD, then the BLD team
will take it over, otherwise not.
... Point is NOT to compete between BLD and PRD.
... Only the presentation/structure of the PRD document seems to be useful.
Jos: Concern that a lot of material of this PRD draft is a repetition of what's already in BLD. But it should only be in ONE place.
Jos: I thought we dont want to have negation in Phase 1. Now it's in PRD.
Sandro: OK for exploratory purposes.
Gary: Until we dont have such extensions of the Condition lang. we should ask them to add them, not invent them in PRD. Rather PRD should move on to formalizing Actions.
Sandro/Axel: Which kind of negation is appropriate for production rules.
<AxelPolleres> sandro, we don't have subclassing in XML, but we do have it in RDFS :-)
Harold: Granularity of reuse better when there are sublanguages of the Condition lang.
<sandro> csma: I really want a common component library, and maybe a common core. BLD and PRD should draw from those, but not have to be exactly the same.
csma: Library of constructs may be advantageous.
<AxelPolleres> I think, which I said already some times admittedly: s/ common Core
<AxelPolleres> /common abstract model/
AdrianP: Many Reactive lang. have such a library.
<AxelPolleres> that would keep the "component library" somewhat "dialect independent"
csma: Uniterm: We cannot say informally only in the spec
that the arg order matters.
... Semantics of Uniterm: mapping function.
Axel: No semantic difference between builtins and user-defined functions.
csma: Currently, not distinguished in BLD.
<sandro> AxelPolleres, while we have subclassing in RDFS, do you think we can mandate that RIF Consumers do complete RDFS reasoning before extracting the RIF semantics structures? That seems like a fairly hard sell to Gary. :-)
csma: in PRD we have fixed interpretation functions.
<ChrisW> Scribe: Harold
Gary: Plus: all args of builtins must be ground.
csma: Yes, that was in the patterns.
<AxelPolleres> For Gary, nothing changes, I don't say that the XML syntax for PR needs to accept <smsnaf> in place of <naf>
Gary: So we have no universal semantics that tells us for
every expression if it's true or false.
... Would be nice to have a more general semantics for both.
<AxelPolleres> but a stratified datalog dialect should maybe accept sms-rulesets, as long as they are stratified.
<AxelPolleres> At least by subclassing , you can define some trivial fallbacks.
csma: That this is not (only) a model-theoretic semantics is even clearer for the And: works also for operat. semantics.
<sandro> Attendance note -- observing for the afternoon has been Carine Bournez, http://www.w3.org/People/carine/ (The RIF meeting is listed on the conference schedule as being open to observers, by accident.)
<AxelPolleres> i.e. if a dialect supports the conceptual superclass semantically, the default fallback would be replacing the special with the more general one.
MichaelK: You have to be careful where you are talking
formally and where informally.
... We prioritized model-theor., then fall back to operational, then to procedural.
... But this is none of these, it's mixed.
csma: It's formal (although written in English).
... Define when a condition is true.
... then execute the actions.
MichaelK: OK, but it's kind of confusing. Suppose I read this, but wont understand.
<sandro> AxelPolleres, so the subclass relationships in the abstract model automatically generate some fallback substitutions? My guess is that's reasonable and somewhat helpful, but I'm not sure.
csma: This is why put sem on top.
... Dont see why this is not formal.
MichaelK: First do syntax, then semantics.
<AxelPolleres> that would be the idea... also not 100% sure, needs some dialect examples, which I still owe, admitedly.
MichaelK: E.g. it's not interpreted as a function from to, everything is regarded as matching.
<AxelPolleres> ... but it sounds appealing to try to me
csma: The pattern matching mechanism gives me the function.
Chris: What do you regard as the interpretation function?
csma: A mapping to a domain element.
... What does pattern matching do? Tells you what's the interpretation!
... Tells you what's and what's not in the interpretation.
... But what I get from discussion: This is confusing. Not the right way to put it in a spec.
... However, the earlier approach also seemed confusing.
... Wanted to keep it as close to BLD as possible.
Harold: Much better than earlier version.
MichaelK: What's wrong: You say here's a program, I determine from a procedure what the meaning is. The wrong way round.
csma: Perhaps misunderstanding.
... Removed pattern section.
... Actions have to be worked on.
... Gary's point is valid that top-level of Rule syntax is different unnecessarily from BLD.
... But this is because BLD is not frozen yet.
... Could perhaps just one CONDITION rather than two. Historical from earlier patterns and the 'else' parts. But it may be good to keept both.
Restart at 4PM.
<StellaMitchell> ScribeNick: StellaMitchell
csma: we didn't consider carefully which xsd datatypes to pick
Chris: Yes, we settled on a set during one of our meetings
... (projecting list of xpath functions and operators)
jos: will these be predicates or functions in BLD?
Chris: do we have notion of builtin as external call? are all predicates, all functions ?
Harold: telecon with DARPA demo group - we chose a fixed
interpretation for builtins
... the point is - we have equality in RIF
mk: if we assume URI's identify functions, we can
Harold: mode declaration of functions
... for now, it would be very nice to have builtins as functions
axel: for predicates, it is not so clear what is input and output
<sandro> binding patterns == modes
<sandro> Harold: non-deterministic builtins
Harold: (something is) then you would have non-deterministic functions
Sandro: trying to clarify between functions and predicates
... you might have extension that has more builtins (that the dialect it extends)
<Harold> Because in RIF we have Equal, we can finally come back to builtins being functions, not (artificially) relations. Advantage: uniform mode declarations.
Sandro: can lead to a language conflict (syntax has different meaning)
Chris: Also, datatype extensibility is an open issue
<sandro> Sandro: It should be a syntax error to use a builtin that's not in some dialect.
Chris: I don't think it makes sense to assume the list of builtins is fixed
Jos: xpath uses namespaces, but we use curies...
csma: functions as relations, means uniterms of the atomic
... so the only uniterm of the term kind are logical functions
mk: asking about xpath urls, namespaces, what is behind it?
axel: reads definition from xpath spec
Sandro: they are available to users as other symbols
<Harold> For example, NumericAdd has uniform mode In
x In -> Out as used in ?Result = 23 + 17 or
Chris: back to questions - builtins as relations or external calls?
csma: what is the difference?
sandro: diff between interpreted and logical functions - for interpreted, you have to call some other piece of code to evaluate it
csma: Allowing user-defined interpreted functions?
sandro: that wouldn't allow for extensibility
csma: producer and consumer have out of band agreement on
what it is
... function names are iris, so if you can't recognize it, you don't handle that external functions
sandro: no, in that case it could be a logic function
csma: I can't think of any concrete case where it would be a problem
sandro: append - would be reasonable as either
Chris: what is the status of functions in BLD
... how does a user define a logic function?
Gary, MK: they just use it
<sandro> "logic functions that are term constructors" vs "evaluable" or "interpretable" functions, ....?
<Harold> In my example, NumericAdd as a relation would have hetereogeneous mode Out x In x In.
sandro: an "eval" function
<sandro> "external call", "procedural attachment", ...
sandro: it's a little confusing that an external call is a
... issue is, if you can tell from the syntax whether it is a builtin or a logical function
Chris: is anyone opposed to having a special syntax to distinguish?
<Harold> We already can define functions using ATOMIC Equality facts based on ATOMIC ::= Uniterm | Equal.
csma: if we want fully stripped xml syntax, we need elment
mk: builtins are supposed to have a uri, and in semantic web uri already has a meaning, so from that point of view we don't have to say anything
sandro: gives example showing it is more complicated
mk: uris are supposed to be self-denoting
sandro: op:numeric-add is self denoting
Chris: is it possible to define syntax and that would indicate which it is?
<Harold> We can user-define as an equational fact
fatherOf(Mary) = John or
mk: no, I don't think so
sandro: dereference argument and get documentation and
links to downloads
... but from point of view of semantics, it is just an opaque string that denotes a function
Chris: syntax that denotes builtins, and spec says which
ones have to be supported
... and people would be able to add more
mk: we can't control what is at the URL of fn:compare
sandro: uri goes to the text description
<AxelPolleres> <Uniterm> vs <Builtinterm>
Chris: advantage of having an explicity syntax is that it
is open - people can add more
... who thinks we should special syntax to identify builtins?
(people on both sides, there is disagreement)
Harold: in lisp there is a uniform way to call user defined and builtin functions
Chris: but in lisp, it is not open
axel: you are saying builtin terms must always have fixed interpretations
mk: I think we can make it extensible
Chris: but you are signalling it syntactically, like with defun
mk: I would use "require" (the list of bld functions)
sandro: that is not extensible
mk: we only care that a symbol is used consistently
... if not, things are broken anyway
sandro: "append" example, where it could be either builtin or logical function
mk: but it would have different uris for different uses
axel: what if the builtin is in the head (conclusion)?
Chris: we can discuss that later, after we resolve this
... if we syntactically mark builtins, it is very clear how it would work
... but some people here think it's cleaner to not have to syntactically indicate it
... proponents of not syntactially marking can try to come up with a suggestion, maybe in a break out tomorrow
<sandro> Chris: Result --- default is External Calls In Syntax; people who want something else (including him) need to come up with a proposal.
Chris: that group will come up with a proposal or agree to the other method
<Harold> Looking at
<Harold> <op><Const type="rif:local">fn:subtract-dateTimes-yielding-dayTimeDuration</Const></op>
... meta means "after"
... what metadata do we need?
<Harold> the "fn:" in fn:subtract-dateTimes-yielding-dayTimeDuration shows that we have an external call here.
Chris: which syntactic terms can have metadata?
<Harold> However there are some ways to mark this more explicitly as a builtin call:
Sandro: and other questions about metadata: is the metadata fixed for a given dialect?
Chris: you mean is there a finite set of preset tags?
PaulV: is it extensible?
<Harold> * Use <Const type="rif:builtin">
Sandro: or rather, if you want a new metadata item, do you need to make an extension?
Gary: can you always ignore the metadata and get the same result?
<Harold> * Use <Const type="rif:local" builtin="yes">
PaulV: what is an example of metadata that cannot be ignored?
<sandro> csma: is rule priority metadata?
<sandro> csma: it affects semantics.
jos: if you refer to a datamodel using metadata, and that datamodel affects the semantics
Sandro: this is why I advocate having no metadata
Adrian: example of using RIF document as data
<sandro> no metadata mechanism --- just more extensions.
Chris: do we want to talk about a class of metadata that cannot be ignored?
csma: I think Sandro had a good point. We don't call it metadata, just data
<Harold> * Both of the above are much better than using a totally different calling method such as <ExternalUniterm>, because the transition from user-defined to builtin should be kept as simple as possible (see above discussion about lisp and prolog).
Sandro: I suggested pushing this off until we understand extensibility better
Chris: It should not be that you need an extension to add author metadata
csma: isn't metadata the things that don't have to do with semantics
mk: dublin core
PaulV: and that (dublin core) would be a good starting point for RIF
jos: we shouldn't have a fixed set of metadata - it's just a set of attribute value pairs
sandro: so properties are iris and values are strings?
mk: sandro, what did you want?
sandro: import dublin core wholesale
<Harold> I think metadata should be non-prescriptive annotations, i.e. not change the normative semantics of a ruleset.
mk: how does owl do it?
jos: they say you can use any metadata you want, as long as it is an annotation property
Chris: I think that agreeing on specific metadata tags
should not be part of dialect defintion - just say how to include
... who thinks the set of metadata for a dialect is fixed?
csma: can we have both? a required set and a way to add more?
Chris: 3 proposals:
... 1 fixed
... 2 open
<Harold> Metadata thus act just like comments from the perspective of the normative semantics, although non-semantics-preserving processing such as in AdrianP's author-filtering example will be possible.
Chris: 3 required, plus a way to add more
sandro: I object to passing a resolution now because we hav not settled on our extensibility mechanism
official count: fixed: 1, open:4, mixed: 6
Chris: We will put on hold the question of where we can put metadata (which elements to attach it to)
<sandro> Chris: Non-ignorable metadata is part of a dialect. I think we have consensus.
Chris: non-ignorable metadata is part of a dialect definition
bobm: i'd say non-ignorable metadata is not metadata
<sandro> Sandro: So the question is whether to have an annotation mechanism for ignorable content.
<sandro> Gary: 'this rule is effective during the month of november' --- is that metadata?
Chris: the mechanism we are talking about is the
annotations that don't affect the semantics
... ( the ignorable metadata)
<Harold> +1 to bobm
<sandro> The issue here is whether to provide a syntactic mechanism for including structured annotations which have no effect on the semantics. And if so, how?
<sandro> (Avoids the term metadata)
<sandro> general consensus on that issue statement.
<PaulVincent> Paul: proposes some use cases for metadata eg RIF for execution won't need metadata eg RIF for rules mgmt will find metadata significant
<sandro> Sandro: I'm not convinced we need this, yet. I think light-weight extensions might cover these use cases.
<mdean> scribe: Mike Dean
Chris: we will discuss it more after we settle on the extensibility mechanism
<mdean> scribenick: mdean
ChrisW: overview of test cases in WebOnt WG
entailments for each operator
resolution of issues often documented as test case
ChrisW: RIF could adopt this methodology
Sandro: consistency tests too?
<sandro> Agreement -- we need Inconsistency and Consistency tests too.
csma: have people submit cases where they think there is
... what is the form of these tests?
example test case in Stella's email above
structured annotations wrapping OWL documents
premise in one file, conclusions in another
<josb> owl example: http://www.w3.org/TR/owl-test/byFunction#function-Restriction
message uses example URIs - OWL tests were real
Sandro: likes .hrif for presentation syntax
... Jeremy Carroll wrote nice software to manage test cases for WebOnt
... recently asked to resurrect this for OWL WG
... Jeremy and Jos deRoo just did it
Adrian: need separate query language?
ChrisW: not needed - just specify in manifest
... can we leverage JUnit?
Sandro: let's wait for a few weeks on OWL WG
ChrisW: need time limit
Sandro: ... unless someone else volunteers
... could still submit a test in natural language in email or Wiki page
josb: good to link to examples in document
csma: some tests should also be linked to use cases
Sandro: group seems to be comfortable mirroring what OWL did
csma: what about testing implementations?
Sandro: WebOnt generated table of tests by implementation, showing each was handled by at least 2
csma: could be a way to test that specification meets requirement, i.e. was implementable
Sandro: doesn't ring any bells
Sandro: prefer conformance
csma: yes/no test or degrees of conformance?
... define profiles/levels
ChrisW: based on test cases that implementation passed, not a formal thing
josb: normative OWL test cases section on conformance
... syntax and consistency checkers
parking passes distributed
<Harold> We need to make entailment ( |- ) relative to the logic we are in. Eg in FOL p(a) :- q(a) |- ~q(a) :- ~p(a), but not so in Horn logic.
Sandro: strawman conformance test: phrase as some sort of ACTION: this software does this ...
csma: prefer one level of compliance - must implement
... then could have compliance for specific extensions
Michael: most implementations probably won't implement
... OWL has not been fully implemented either
josb: Pellet isn't complete with nominals
Sandro: unfortunate that we don't have complete OWL implementations yet
Michael: same with SQL, thousands of pages of spec
... don't exclude something just because it's hard to implement
csma: compliance is like conformance but not quite :-)
... want to promote adoption, motivate comfortant implementations
Michael: could be conformance level that doesn't include equality
csma: could end up with so many dialects and levels that OWL looks simple
<Harold> The paramodulation calculus is a refutational theorem proving method for
<Harold> first-order logic with equality, originally presented in Robinson &Wos (1969)http://www.cs.bu.edu/fac/snyder/publications/BasicParamodulation.pdf
<sandro> Chris: Issues 1 - whether to have levels of conformance (vs just boolean) per dialect
<sandro> Chris: Issues 2 - whether to have lowest conformance level match implementations (eg full equality).
bob: many features aren't implemented or implementable
with reasonable time
... interoperability is most important
... don't define logic that can't be implemented
<sandro> Chris: 4 square, levels vs expected.
csma: boolean might not require equality
profiles not the same as levels
Chris: boolean per dialect
Michael: profiles are kinds of dialects
<sandro> Chris: Levels + Expected: 0
<sandro> Chris: Booleans + Expected: looks like everyone
<sandro> Chris: Boolean + Not-Expected -- Michael
<sandro> Michael: There will be useful implementations which don't conform.
<Harold> The axioms for the equality relation need not be built into RIF (without it's easy to implement), because they can be 'loaded' as another ruleset: http://www.math.psu.edu/melvin/logic/node7.html
Chris: does everyone assume profiles?
6 of N-1 thought they were voting for profiles
<sandro> Voting for profiles: 6,
Sandro: voting for compliance being something that's implementable
Chris: BLD - equality not a profile?
Sandro: change BLD to not include equality
csma: current BLD becomes an extension
<sandro> Sandro,Bob: define BLD as something that's implementable.
+5 for Sandro
<sandro> 5 people agreeing with that view.
csma: same for PRD
... extensions could be harder to implement
Sandro: profile vs. extension is marketing difference
csma: important for adoption
Sandro: same for equality and negation
Chris: plenty of SQL operators are partially implemented
... nobody needs the full implementation
csma: must jump start implementations
Chris: not ready for resolution, but consensus that we want boolean tests for conformance with some disagreement over what to test
Michael: could also use test cases
Chris: industry likely to do this, publish their test case results
Sandro: BLD querying system vs implementation
Chris: do we need issue regarding equality?
... always boils down to test cases
<sandro> group of five who wants BLD changed to remove quality, so that it's practical to implement it fully
<sandro> ACTION: Christian to open issue about removing equality from BLD because it's not so practical to implement. [recorded in http://www.w3.org/2007/11/05-rif-minutes.html#action09]
<rifbot> Created ACTION-366 - Open issue about removing equality from BLD because it\'s not so practical to implement. [on Christian de Sainte Marie - due 2007-11-12].