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?

I have not written many knowledge bases.  I also cannot claim that I can
foresee all possible ways people might use rules.  I also do not think
that the possibility that people might use a particular feature in the
future is a good reason to include that feature in a language.  There
are endlessly many features one can think of, so one would make the
language endlessly complex.

My choice of the label "toy example" may not have been entirely
accurate.  I am looking for examples in which people would need the RIF
membership or subclass relation, rather than simply encoding their own
membership and subclass constructs which correspond to their own model.
It has been argued that the use case for the membership and subclass
constructs are the integration of different notions of membership and
subclass.  However, I have not seen any such concrete use case so far.

> 
>> 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.

Well, the fact that rdfs:subClassOf is part of the domain does not have
serious consequences in most uses.  However, you are right that in most
systems the subclass relation itself is not part of the domain.

However, I could similarly about the membership and subclass relations
you proposed.  Namely, classes are interpreted as elements of the
domain, which is also not commonly accepted.  At least not in any
DL-based systems.

So, this means that the membership and subclass relation you propose can
not always be used for the representation of membership and subclass.

> 
> 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.

You seem to say that RDFS is not a powerful enough ontology modeling
language?
I don't really see this as an argument to replace it, but rather as an
argument to extend it (e.g., using the RIF-RDF combination mechanism).

> 
> 
>>> 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?

It introduces two additional kinds of atomic formulas, plus some
conditions on the semantic structures.  Furthermore, it introduces yet
another ontology modeling language for the semantic Web.

> 
> 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?

I have only done a preliminary study  for defining a stable model
semantics for RIF-RDF combinations.  Complications arise from the blank
nodes; however, membership and subclass are rather straightforward.
Of course, rdf:type and rdfs:subClassOf are part of the Herbrand
universe; then again, so are the constants in all supported datatypes.

> Can you voucher that there would be no complications for those
> dialects?

As I said, I've only seen complications arising from blank nodes.  The
definitions of membership and subclass are rather straightforward, so I
do not expect any complications there.  Then again, the study was only
preliminary.

That said, I do not want to force everyone to use RDFS for ontology
modeling; I am rather skeptical about the usability of the # and ##
constructs as a unifying ontology language.

Best, Jos



> 
> 
> 	--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--
>>
> 
> 
> 

-- 
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