See also: IRC log
<ChrisW> Meeting: RIF Telecon
<ChrisW> Meeting: RIF Telecon 18 Sept 2007
<ChrisW> Scribe: Adrian Giurca
<AllenGinsberg> zakim aaaa is me
<PaulaP> :)
<AxelPolleres> :-D
<PaulaP> agiurca is Adrian Giurca
<ChrisW> adrian G are you here?
yes. I'll be on the phone too.
<ChrisW> adrian, you had agreed to scribe today?
Yes, I will scribe
<ChrisW> http://lists.w3.org/Archives/Public/public-rif-wg/2007Sep/att-0085/11-sept-07-rif-minutes.html
<ChrisW> RESOLVED: accept Sept 11 minutes
<ChrisW> scribenick: agiurca
ChrisW: F2F8 in Nov. 5-6 , Boston
<josb> http://www.w3.org/2005/rules/wg/wiki/Core/RIF-RDF_Compatibility
<Harold> Couldn't the 'extension rules' always be specified in a fixed subset of BLD?
<Harold> (independent of the BLD dialects)
josb: This combination has his own semantics
... the semantics is an extension of BLD and RDF semantics
MichaelKifer: Embeding do not need any new task
... You need an embedding in oder to use RDF and RIF together
... Otherwise you have to implement another language that extend both RIF and RDF
... Embedding is the only thing that we need
josb: Explain why we need a new language in oder to use RDF and RIF together
<AxelPolleres> from our charter (not sure whether directly related): "Note that the natural overlap in expressivity between this language and RDF means this syntax should function as an alternative XML serialization for RDF Graphs (or at least a subset of RDF Graphs)."
MichaelKifer: Without embedding people have to implement all kind of translations
<Hassan> +1 with MK ...
josb: is the embedding just a syntactic representation of RDF in RIF?
+1 with MichaelKifer solution
MichaelKifer: We need just
embedding and model theory is redundant
... Otherwise the users must decide how to do the embedding
josb: another argument in favor
of model theoretic approach is that this is according with W3C
recommendations
... You can do reasoning with RDF using this embedding. If you
have the embedding you don't extend the existing RDF
semantics
... My proposal is to do everything with model theory
... Otherwise you need specific rule sets or specific
constructs for queries...
MichaelKifer: Even with model theory you have to check consistency
<Hassan> +++1 for MK's point!
<PaulaP> +1 to Michael's comment
MichaelKifer: Embedding is simple and straightforward to explain to people
<JeffP> sorry for the late
ChrisW: I guess examples are good to illustrate both approaches and they are desirable
josb: There is a second point:
the relation with RDF semantics document
... First we have to decide about the OWL - RIF
compatibility
IgorMozetic: Josb: What is the vision of the implementation?
josb: the implementation uses embedding
IgorMozetic: So, you need embedding anyway
josb: No you don't need that
Hassan_Ait-Kaci: I just want to emphasise the Michael Kifer point
... the embedding is straightforward as is that of FOTs for the most users
of Prolog...
... most RDF users have no clue about P. Hayes' RDF semantics, which BTW is
neither complete, nor the most simple or most elegant one a formalist
could fancy...
... for users, an RDF graph is just that: a *graph* data structure (just as
a FOT is just a tree data structure for a Prolog user rather than a
Skolem function dependency of an existential variable on all the
universal variables that precede it !)...
+1 for hassan points. for RIF, RDF is a data model
<DaveReynolds> Adrian, Hassan - the embedding proposal proposes embedding the semantics (as rules) not just as a data structure
Michael_Kifer: making embedding normative will establish how RIF works with RDF
Dave, this is like in Jena no? That's why the embedding is sufficient
<Zakim> sandro, you wanted to say redundancy isn't necessarily bad. readers don't have to read both -- just the one they want.
Michael_Kifer: I propose to split the document in two parts
<AxelPolleres> +1 to separate documents eventually
<AxelPolleres> ... and keeping model theory.
Michael_Kifer: I don not want the model theory in the sample document
<josb> we are also chartered to produce an OWL compatibility doc; RDF compatibility should also go in there
<PaulaP> +1 to have two docs
<Harold> Michael seems to say: we dont want an extra barrier to entry.
<ChrisW> ack Harold
<sandro> (I didn't feel Chris' summary addressed the issue of DaveReynolds's point about reverse engineering.)
Hassan_Ait-Kaci: An example may be any rule set dealing with metaprogramming where terms denoting predicate calls are used at both the predicate and term level. I would be curious to see how Jos's would-be normative (!) model-theoretic semantics renders such RDF/S applications - which all users of such rules should of course be intimately familiar with since it'd be normative...
AxelPolleres: we might not know now which of the approaches is more complex
... I think we need two documents
josb: we are also chartered to produce an OWL compatibility doc; RDF compatibility should also go in there
<AxelPolleres> Well, there is a lot of stuff which people who only need to use bld wouldn't need to care about (e.g. multiple truth values, etc.)
<sandro> (I agree --- the Charter doesn't tell us how we need to organize our text into documents.)
chrisW: we don't really need a separate document on compatibility. We can just need to address compatibility with both RDF and OWL
<AxelPolleres> Could an intermediate solution be putting the model theory in an appendix and refferring to from the rules (stating that these are derivable from the model theory?)
<PaulaP> I did read it
<DaveReynolds> I have glanced through it
<AxelPolleres> have had a glance today.
<Hassan> I have glanced thru it
<DougL> Not in the last 2 hours!!
<GaryHallmark> I skimmed it
<JeffP> not yet
<AdrianP> i did
Harold: It was a little time to study the document since it was updated just two hours ago
<DaveReynolds> Harold - OWL is not based on RDF/XML it is a based on RDF that was the problem, Sandro's proposal is not for an RDF serialization
<GaryHallmark> -1 for rdf/xml
<Harold> DaveR, it's instructive to re-read: http://www.daml.org/listarchive/joint-committee/1635.html
<PaulaP> It is not clear why we should go for RDF/XML
<josb> yes, there can be confusion between RDF as syntax for RIF and RDF as data set/model for RIF rules
<PaulaP> +1 to Axel's comment
<Harold> Human-readable greaterThan(?diffdate 10), if greaterThan is a SWRL Built-In,
<Harold> should become serialized as (since full striping was decided):
<Harold> <Uniterm>
<Harold> <op><Const iri="http://www.w3.org/Submission/SWRL/#8.1">greaterThan</Const></op>
<Harold> <arg><Var>diffdate</Var></arg>
<Harold> <arg><Const>10</Const></arg>
<Harold> </Uniterm>
<GaryHallmark> is there a difference between "local named constants" and "literal data values"?
<DaveReynolds> Harold - how can http://www.w3.org/Submission/SWRL/#8.1 be the iri for greaterThan?
<Harold> It's currently the most fine-grained we have.
<Harold> For more completeness, we could create: iri="http://www.w3.org/Submission/SWRL/8.1/#greaterThan"
May be http://www.w3.org/2003/11/swrlb#greaterThan
<DaveReynolds> Harold - so what's the relation between the IRI and the element content (i.e. "greaterThan")
but is the same ideea of course
<AxelPolleres> I proposed: &op;numeric-greater-than
<AxelPolleres> ... which would however require us to provide a namespace for the op: prefix used in the XPath-functions document
<Harold> You point to the specifying passage of the official document.
<AxelPolleres> Note that I ran in pretty many of the mentioned issues in: http://www.w3.org/2005/rules/wg/wiki/UC10_Worked_Example
Hassan_Ait-Kaci: local names follow a scoping mechanism
<Harold> +1 to Hassan: also in the draft we already have a notion of rif:local <http://www.w3.org/2005/rules/wg/wiki/Core/Positive_Conditions>.
<Harold> "Basic RIF logic also defines two additional symbol spaces, rif:iri (for international resource identifier or IRI) and rif:local (for constant symbols that are not visible outside of a particular set of RIF formulas)."
Michael_Kifer: There is already a syntax of these in the current document. There is no need for special elements for the local and global names
<Hassan> The XML syntax should reflect the spec
<Harold> There's already <Const type="xsd:long">49</Const> in <http://www.w3.org/2005/rules/wg/wiki/Core/Positive_Conditions>.
<PaulaP> bye
<JeffP> +1
<JeffP> bye