[TF-ENT] Agenda for this week's ent. regimes teleconf

Hi all,
I've read the RIF sections and I am really happy about the progress
that I see. Much better than anything I could produce with my limited
RIF knowledge. I'll try to compile the main open points (taking into
account Ivan's and Chime's own comments) for our teleconf on Wednesday
below. If you have any additions or amendments, please let me know. I
also have a few smaller/editorial comments, which I'll send in a
separate email.

* Date of Call: Wednesday March 10, 2010
* Time of Call: 18:00 UK, 13:00 (East US)
* Dial-In #: +1.617.761.6200 (Cambridge, MA)
* Dial-In #: + (Nice, France)
* Dial-In #: +44.117.370.6152 (Bristol, UK)
* Participant Access Code:
   Zakim will tell us when the ad hoc conference is set up
* IRC Channel: irc.w3.org port 6665 channel #sparql
* Duration: 60 minutes

 o Proposed RIF entailment regime
  - Safe vs. Strongly Safe, we use both, should we always use the
strong variant?
  - Why do we need (C2) for the RIF-RDF case? Will we have separate
entailment regimes for RIF
Core combined with RDF, RDFS, and OWL Full/DL?
  - Editorial note: The 8th condition of a common-RIF-RDF-interpretation:
    includes the set-theoretic semantics of rdfs:subClassOf that are
also used by the RDFS Entailment regime.
  - What's the best imports URI: sparql-rif:useRuleset,
rif:useRuleset, or rif-rdf:useRuleset/ I thought we had an agreement
for making it SPARQL specific, but that maybe applied to the fact that
the definition is part of the net. regimes doc, but not necessarily
the namespace.
  - Embedding a subset of RIF-OWL combinations (OWL 2 RL for instance) as
extensions to this entailment regime (issues of consistency checking,
axiomatic triples and rules)
  - A mapping from all the SPARQL builtins to corresponding RIF
builtins (beyond those in the RIF Datatypes and Built-Ins document)
could further close the expressive gap between RIF Core and SPARQL.
They would most likely all be safe (and maybe also strongly safe).
  - Are there examples of RIF Core (normatively) safe rulesets /
documents that use builtins that do not introduce new values into the
domain that are useful as arguments against the finite restrictions?
(extant N3 Logic / CWM builtins don't really do that except the
obvious log:semantics, etc.)

Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
United Kingdom
+44 (0)1865 283529

Received on Monday, 8 March 2010 15:33:36 UTC