Re: Reminder: pending discussion "membership" (pending discussion on ACTION-350)

> > CSMA had an action to bug me about the ## feature :-)
> > I thought that others might also be interested, so I am including my
> > arguments below.
> > 
> > First, one needs to be able to specify that one class is a subclass of
> > another class **as part of the KB**. For instance, 
> > 
> > student##person.
> > father(person)##person.
> > 
> > In KB apps this is used for reasoning, not just as part of a data
> > model. How would one specify this info otherwise?
> > 
> > Here is a more sophisticated example: parametrised lists.
> > 
> > list(?Subclass) ## list(?Super) :- ?Subclass ## ?Super.
> > 
> > (List of FOOs is a subclass of lists of BARs if FOO is a subclass of
> > BAR. We could have list(father(person)), for example.)
> 
> I have yet to see a real use case for the inclusion of either membership
> or classification in RIF.  One can always create toy examples,

This is a toy example?

> but I wonder who is actually going to use the features.

I must say that I was taken aback by your assertion about a toy example
above.
I do not want to get personal here, but how many knowledge bases (which
actually work) have you written? Why do you think that you can foresee all
the possible ways people might use object-oriented rules, and why do you
think you are a good arbiter to decide which examples are "toy" and which are
not?

> Are there any use cases for the use of these features for the
> integration of several notions of membership or subclassing?
> In the use cases I've seen so far, everyone encodes its membership or
> subclass relation in his preferred way, but I haven't seen use cases in
> which different notions of membership or subclass are integrated using
> the proposed subclass or membership constructs in RIF.

I do not know if we need such use cases. But it is easy to map other
subclass relationships into ##, as we discussed.


> > RDF's subclassOf does not cut it because
> > 
> > 1. It imposes additional axioms, which are not commonly accepted.
> 
>   Do you have references to back up this statement?

To provide references to a negation of a universal, I only need to give
examples of systems where this notion is not accepted.

The fact that rdfs:subClassOf is part of the domain is an idiosyncrasy of
RDF and it needs not be pushed down the throat of every language out there.
E.g., DL-based rile languages like SWIRL or several of the F-logic-based
languages.  Other KBs like LOOM also do not have this. In fact, RDF is the
only one that makes this strange assumption among the KB languages that I
know of.

Now, reflexivity of the subclass relationship is less controversial.
In fact, when we defined F-logic, we defined the subclass relationship to
be reflexive. But when we started to actually **use** it, we found that in
virtually all cases we had to write something like  ?Foo##?Bar and ?Foo != ?Bar.


> > 2. It is also not even defined for classes specified using function terms
> >    (like list(?Foo)).
> 
> What you mean with that?  In an RDF-RIF combination, one can specify the
> example you mentioned in the following way:
> 
> student[rdfs:subClassOf -> person].
> father(person)[rdfs:subClassOf -> person].
> 
> list(?Subclass)[rdfs:subClassOf -> list(?Super)] :-
> ?Subclass[rdfs:subClassOf -> ?Super].

This is an extension of the RDF notion. Earlier Dave was telling me that to
define class hierarchies one should use RDF or "my preferred data modeling
language" (not sure how to make use of that suggestion).

Since RDF does not support this, I do not see a point in this exercise.
One could use a property called foobar instead of the above with the same
degree of success.


> > Both arguments are also applicable to the RDF membership relationship.
> 
> The RDF membership relationship by itself does not impose additional
> axioms; it is simply a binary relation.
> 
> Furthermore, it is certainly defined for classes (and individuals)
> specified using functional terms.

Only in your extension.


> > I am convinced that throwing out these primitives serves no purpose and
> > will just gratuitously cripple the BLD.
> 
> I am convinced that including these primitives serves no purpose and
> will gratuitously blow up / complicate the BLD.

By how much does it blow things up?

There is another issue. Have you studied what would happen when one uses your
RDF-based notion of membership/subclass with the well-founded or stable
semantics? Can you voucher that there would be no complications for those
dialects?


	--michael  



> best, Jos
> 
> > 
> > 
> > 	--michael  
> > 
> > 
> > 
> >> Dear all,
> >>
> >> I was asked by Chris to remind again to forward again a reminder on the 
> >> pending discussion about the special notation '#' for class membership 
> >> and in RIF since this should be discussed in the upcoming Teleconf.
> >>
> >> In the last f2f I was asked to send a use case for this, where I sent 
> >> the - obvious - RDF use case, see
> >> http://lists.w3.org/Archives/Public/public-rif-wg/2007Sep/0184.html
> >>
> >> For your convenience I copy this here again:
> >>
> >> --------------------------------------------------------------------
> >>
> >> http://www.w3.org/2005/rules/wg/track/actions/350
> >>
> >> The class membership notation '#' is intended to reflect the common
> >> feature of many rule and object oriented languages for being able to
> >> express memebership of a class (or type?)
> >>
> >> A possible use for this is for RDF's rdf:type construct...
> >>
> >> To reflect this in the current RDF/RDFS embeddings, one could add to
> >>
> >> 1) Add to RDF embedding:
> >>
> >>     Forall ?c,?o ?o#?c :- ?o[rdf:type -> ?c]
> >>
> >>
> >> ------- ACTION done, what follows is additional discussion ;-) --------
> >>
> >> This alone, obviously doesn't make too much sense, but in connection
> >> with the additional subclass notation '##' one could safe two rules
> >> in the RDFS embedding:
> >>
> >> 2) Add to RDFs embedding:
> >>
> >>    Forall ?c1,?c2 ?c1##?c2 :- ?c1[rdfs:subclassOf-> ?c2]
> >>
> >> and remove:
> >>    Forall ?x,?y,?z ?z[rdf:type -> ?y] :- And (?x[rdfs:subClassOf -> ?y]
> >> ?z[rdf:type -> ?x]),
> >>    Forall ?x,?y,?z ?x[rdfs:subClassOf -> ?z] :- And (?x[rdfs:subClassOf
> >> -> ?y] ?y[rdfs:subClassOf -> ?z]),
> >>
> >>
> >> In total, the use of the special notation adds two rules and saves us
> >> two rules in the RDF/RDFS embedding.
> >>
> >> Pretty much equals out ;-)
> >>
> >> That's why I am absolutely neutral on whether we chould keep that
> >> feature or no.
> >>
> >> Axel
> >>
> >> p.s.: Note that I have to send regrets for the next Telecon, since I 
> >> will be travelling most likely (could be I get connection from train or 
> >> airport, but no guarantees.)
> >>
> >> -- 
> >> Dr. Axel Polleres
> >> email: axel@polleres.net  url: http://www.polleres.net/
> > 
> 
> -- 
> Jos de Bruijn            debruijn@inf.unibz.it
> +390471016224         http://www.debruijn.net/
> ----------------------------------------------
> If you live to be one hundred, you've got it
> made. Very few people die past that age.
>   - George Burns
> 
> --------------ms090403020801020107000901
> 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
> 
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJEzCC
> AuQwggJNoAMCAQICEB1TmNgyHOKRUL43eSjaINgwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
> BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
> I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUxMDA3NTMwOFoX
> DTA4MDUwOTA3NTMwOFowRzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEkMCIG
> CSqGSIb3DQEJARYVZGVicnVpam5AaW5mLnVuaWJ6Lml0MIIBIjANBgkqhkiG9w0BAQEFAAOC
> AQ8AMIIBCgKCAQEA4mJofW3+kMtlQKNG0am5Km+8qlA18tMV9Q5oPrOgBoReGVwbcc1oXrSJ
> 1lhTAFjCVjasdS61TpwsYWWzrNfygNKHPVvmDWJRDVUCyqvsLUhhWiIT2GoJCKlWXXpzNdWQ
> e1pXwFCLVniOD+SrWXx4qtdSYk9XmUX/k3ymZupqcGeFIokk+jrA97b2K+7QEwoiyGyStXcU
> NI5r/690Htyck7nmc+tBX5t/aq0EtVpBi4VKNas7Pc4kGb0Knne1VUP1dS3V1GgHg18Vay+D
> p5SjScZiJEYMYk06X7qzJOu79ZpEN87b3pIrnI+j2qrblcrWRH54ovOF0xmMUpbPIYFQLwID
> AQABozIwMDAgBgNVHREEGTAXgRVkZWJydWlqbkBpbmYudW5pYnouaXQwDAYDVR0TAQH/BAIw
> ADANBgkqhkiG9w0BAQUFAAOBgQAApmPQlsZUuIaP4F/Jmev1uvgt/FrcXcVCr9s5YHcoTfl2
> nKrfoev1IXti4w/IY8q1l7AgN3eulgkB0pws0qLQ7dGg812vXO+CEqN9Vs0+0zeOz4l4lppc
> uuppnlj+MKk25ZRFoXs6XGvLZdhupslDZSPgswqkYyj0As67RBSXhDCCAuQwggJNoAMCAQIC
> EB1TmNgyHOKRUL43eSjaINgwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNV
> BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz
> b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUxMDA3NTMwOFoXDTA4MDUwOTA3NTMw
> OFowRzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEkMCIGCSqGSIb3DQEJARYV
> ZGVicnVpam5AaW5mLnVuaWJ6Lml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
> 4mJofW3+kMtlQKNG0am5Km+8qlA18tMV9Q5oPrOgBoReGVwbcc1oXrSJ1lhTAFjCVjasdS61
> TpwsYWWzrNfygNKHPVvmDWJRDVUCyqvsLUhhWiIT2GoJCKlWXXpzNdWQe1pXwFCLVniOD+Sr
> WXx4qtdSYk9XmUX/k3ymZupqcGeFIokk+jrA97b2K+7QEwoiyGyStXcUNI5r/690Htyck7nm
> c+tBX5t/aq0EtVpBi4VKNas7Pc4kGb0Knne1VUP1dS3V1GgHg18Vay+Dp5SjScZiJEYMYk06
> X7qzJOu79ZpEN87b3pIrnI+j2qrblcrWRH54ovOF0xmMUpbPIYFQLwIDAQABozIwMDAgBgNV
> HREEGTAXgRVkZWJydWlqbkBpbmYudW5pYnouaXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B
> AQUFAAOBgQAApmPQlsZUuIaP4F/Jmev1uvgt/FrcXcVCr9s5YHcoTfl2nKrfoev1IXti4w/I
> Y8q1l7AgN3eulgkB0pws0qLQ7dGg812vXO+CEqN9Vs0+0zeOz4l4lppcuuppnlj+MKk25ZRF
> oXs6XGvLZdhupslDZSPgswqkYyj0As67RBSXhDCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcN
> AQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT
> CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp
> ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG
> cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNv
> bTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYD
> VQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy
> c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
> xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV
> cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq
> VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMG
> A1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZy
> ZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp
> dmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIX
> oUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx
> VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x
> ggNkMIIDYAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu
> ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu
> ZyBDQQIQHVOY2DIc4pFQvjd5KNog2DAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJ
> KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEyMTAxMzI0MTBaMCMGCSqGSIb3DQEJBDEW
> BBSz3F1CEMGyd8bp1NZfX9LoKToTEDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G
> CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB
> hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
> bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz
> c3VpbmcgQ0ECEB1TmNgyHOKRUL43eSjaINgwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYD
> VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
> AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEB1TmNgyHOKRUL43eSja
> INgwDQYJKoZIhvcNAQEBBQAEggEATPEs39xKEzaV/E13jdEhGIyNSKsrGWaFzyhtT5X8FAS8
> zSrTYKvUnPJT4USnKKmwVZEdFIFZLV4pqU70Ju6axeBYVa6VQA7Lm4eyVo5aMF0+JUwvAVlM
> Ua7BYR4rTNQGpnH4yR0J0ppk81esBZBMMZe5ShFYwMfTYdFknLDIKRyKOrrVFo6qPe7XM8QL
> EN5s11EdHHKPnQg3i7iHH0IZz9Xdt70cnFeaXauEyGT4YWcj2LQK/aAcAG1ZnM+EhcIcJC+b
> uPwNsUPnJps9KuN7S4T4BN5uwLe2BWQlobXaDiQClFHG3A3YA/8uIXrLmPGsq3Foig+L4XCr
> sRxOSfJQrwAAAAAAAA==
> --------------ms090403020801020107000901--
>

Received on Monday, 10 December 2007 17:01:44 UTC