W3C home > Mailing lists > Public > public-rif-wg@w3.org > April 2008

Re: imports + metadata

From: Michael Kifer <kifer@cs.sunysb.edu>
Date: Thu, 10 Apr 2008 15:25:43 -0400
To: Jos de Bruijn <debruijn@inf.unibz.it>
Cc: Sandro Hawke <sandro@w3.org>, public-rif-wg@w3.org
Message-ID: <20588.1207855543@cs.sunysb.edu>

Jos de Bruijn <debruijn@inf.unibz.it> writes:
... snip ...

> Now to come to my proposal for the semantics of RIF imports:
> A set of RIF rulesets R is imports-closed if, for any IRI i in an import 
> directive in any rule set in R such that i identifies a ruleset r, t(r) 
> is included in R.
> Here, t(r) is obtained from r by replacing every constant with symbol 
> space rif:local  with a new globally unique constant.
> The definition of entailment for RIF rulesets extends to sets of RIF 
> rulesets in the natural way.
> If this semantics is acceptable, we still need to decide whether we use 
> the "directives" mechanism, or whether we extend the syntax of RIF with 
> the "imports" statement.  I don't have a very strong opinion either way.

My preference would be to make it part of the syntax. Something like


Here Directive and Import are not function/predicate symbols, but
logical symbols, like the connectives And, Or, Group, etc.

Moreover, I would not want to define it by expansion. Instead, let
contents(iri) denote the top-level formula of that document (which is
now a Group(...) formula, but could become a Document(...) formula, if we
add that, and put this into the semantics:

    I |= Directive(Import(iri))

iff for every I*

    I* |= contents(iri)

where I* is a semantic structure, which is the same as I except that I*_C, I*_F,
I*_CF may differ from I_C, I_F, I_CF on the symbols ^^rif:local.

This makes it easier to integrate import with the future, more general,
mechanism of modules. This also avoids iffy statements, like "t(r) is
obtained from r by replacing every constant with symbol space rif:local
with a new globally unique constant." This statement already has some
problems. For instance, what exactly is "global" and why should it be
globally unique? It probably should be unique to the merge document.
The replacement constant also must come from ^^rif:local, by the way.

In addition, I am not sure that your definition is necessarily the "right one."

Consider this:

**main rule set:
import iri...

some other rules.

**rule set at the iri:

Now, I am asking a query like this *in the main rule set*:

?- p(?X).

according to you, the answer should be ?X = some constant other than
"abc"^^rif:local. But I think it should be ?X = "abc"^^rif:local.
I admit that this is a weird example, and probably one should not write
such stupid rules, but still.

By the way, what I described is basically the Prolog semantics, although
Prolog does not define this formally AFAIK.

> Now to come back to the issue of referring to/importing RDF/OWL:
> We have two somewhat orthogonal issues:
> a- how to refer to the RDF graph/OWL ontology
> b- how to decide which entailment regime to use
> It would of course be possible to leave both things out of RIF, but I 
> think we should at least give people the chance to refer to RDF 
> graphs/OWL ontologies.  I also have the feeling that most people in the 
> working group would not have a problem with that.
> First of all, the shape of such a reference would depend our earlier 
> decision between directive/syntax extension.
> Then, I see three ways to include such references:
> 1-  use the RIF "imports" statement.  An advantage would be that we use 
> the same key word for all things that are "imported".  A disadvantage 
> would be that the term is overloaded.
> 2- define a new keyword, e.g. "data source reference"
> 3- define a range of keywords, one for each entailment regime, e.g. 
> "importOWLDL", "importOWLFull"
> If we would go for option 3, we would immediately solve the second issue 
> (b).
> Personally, I don't like option 3, because it always requires to specify 
> the entailment regime.  I would like to make it optional.
> Then, I have a slight preference for option 2, because it matches my 
> intuition, but I would not have a problem with option 1.
> concerning issue (b):
> 1- If we want to include references to entailment regimes, we can 
> include a keyword "entailmentRegime", and invent IRIs for the respective 
> entailment regimes.
> 2- Another possibility would be to include "switches", i.e., define a 
> new keyword for each entailment regime and inclusion of such a keyword 
> would mean you want to use it.

I think it should be

Directive(Import entailment-regime (iri)).

(Again, keep in mind that Directive and Import are not function/predicate


> Best, Jos
> [1] http://www.w3.org/2005/rules/wiki/SWC#Annotation_properties
> > 
> > 
> > I suspect this isn't your style, Jos :-)  -- I don't think it's a 100.0%
> > solution, you have a squint a little --  but it has a certain elegance
> > which might make it worthwhile.
> > 
> > Thoughts?
> > 
> > Oh, I should also note that folks have been working on clearing up OWL
> > Imports with a new spec for OWL 1.1 [3].  I haven't read it yet.  (I
> > doubt it addresses this perspective -- OWL pretends (sometimes
> > awkwardly) to have a subset relationship between dialects, so there is
> > less need to care about which one you are using.)
> > 
> >       -- Sandro
> > 
> > [1] big table near the bottom of
> >     http://www.w3.org/2005/rules/wg/wiki/AbstractModel
> > [2] http://www.w3.org/2007/OWL/wiki/XML_Serialization
> > [3] http://www.w3.org/2007/OWL/wiki/Imports
> > 
> -- 
> Jos de Bruijn            debruijn@inf.unibz.it
> +390471016224         http://www.debruijn.net/
> ----------------------------------------------
> Doubt is not a pleasant condition, but
> certainty is absurd.
>    - Voltaire
> --------------ms080106070909030609070101
> Content-Type: application/x-pkcs7-signature; name="smime.p7s"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment; filename="smime.p7s"
> Content-Description: S/MIME Cryptographic Signature
> AQ8AMIIBCgKCAQEA4mJofW3+kMtlQKNG0am5Km+8qlA18tMV9Q5oPrOgBoReGVwbcc1oXrSJ
> e1pXwFCLVniOD+SrWXx4qtdSYk9XmUX/k3ymZupqcGeFIokk+jrA97b2K+7QEwoiyGyStXcU
> NI5r/690Htyck7nmc+tBX5t/aq0EtVpBi4VKNas7Pc4kGb0Knne1VUP1dS3V1GgHg18Vay+D
> p5SjScZiJEYMYk06X7qzJOu79ZpEN87b3pIrnI+j2qrblcrWRH54ovOF0xmMUpbPIYFQLwID
> ADANBgkqhkiG9w0BAQUFAAOBgQAApmPQlsZUuIaP4F/Jmev1uvgt/FrcXcVCr9s5YHcoTfl2
> nKrfoev1IXti4w/IY8q1l7AgN3eulgkB0pws0qLQ7dGg812vXO+CEqN9Vs0+0zeOz4l4lppc
> uuppnlj+MKk25ZRFoXs6XGvLZdhupslDZSPgswqkYyj0As67RBSXhDCCAuQwggJNoAMCAQIC
> 4mJofW3+kMtlQKNG0am5Km+8qlA18tMV9Q5oPrOgBoReGVwbcc1oXrSJ1lhTAFjCVjasdS61
> WXx4qtdSYk9XmUX/k3ymZupqcGeFIokk+jrA97b2K+7QEwoiyGyStXcUNI5r/690Htyck7nm
> c+tBX5t/aq0EtVpBi4VKNas7Pc4kGb0Knne1VUP1dS3V1GgHg18Vay+Dp5SjScZiJEYMYk06
> X7qzJOu79ZpEN87b3pIrnI+j2qrblcrWRH54ovOF0xmMUpbPIYFQLwIDAQABozIwMDAgBgNV
> AQUFAAOBgQAApmPQlsZUuIaP4F/Jmev1uvgt/FrcXcVCr9s5YHcoTfl2nKrfoev1IXti4w/I
> Y8q1l7AgN3eulgkB0pws0qLQ7dGg812vXO+CEqN9Vs0+0zeOz4l4lppcuuppnlj+MKk25ZRF
> oXs6XGvLZdhupslDZSPgswqkYyj0As67RBSXhDCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcN
> ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG
> xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV
> cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq
> A1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZy
> oUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx
> VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x
> BBSR9ya9un9sp9th6hGFf7O6GyBMuTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G
> bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz
> AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEB1TmNgyHOKRUL43eSja
> INgwDQYJKoZIhvcNAQEBBQAEggEANrjwAA6+sNzZBgo33b3PefakOZhGATcOoR1S82npMgv1
> yacyDUCxOsKmqG1Pn3J/KGlHAbH4wIAmodqMzJIT5bEv9EI7sCi3s5hvcDeQ2eVAP7IM5uYJ
> aTUOkMzI69HKa9yyg6l+HmOIVrMYUXH/ryYnf84dFM0qSLvYHtHlEIyK0805WyRtBiGYyuWp
> Z4C/65jUKai56xECCC3vTZYNiSsXtvtF+1VVoQi4cMT6dF4+gsQOg8/ORDquU5aw+DTuwVIx
> iTsKKjQwZcC74p65Bb2iQ+WcoHlc1iIG3o1Hvsg2Ye5pRYH4+Wr2mT+Real9enL3zOcGP4Nk
> --------------ms080106070909030609070101--
Received on Thursday, 10 April 2008 19:38:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:50 UTC