Re: Issues with classification a#b, a##b

> Michael Kifer wrote:
> > So, given the last part of your response, we basically agree.
> > The right translation, in my opinion, is what you proposed with Jos plus
> > the two (not 4 rules) like this:
> > 
> > ?p # ?t :- ?p[rdf:type -> ?t] .
> > ?p ## ?t :- ?p[rdfs:subClassOf -> ?t] .
> 
> Why not the reverse rules?
> 
> Surely if someone writes a RIF rule for, say, classification:
> 
>     ?p # eg:Manager :- ?p # eg:Employee, ?p eg:manages ?m .
> 
> then in order for any RDF rules (including ones which quantify over the 
> slot name) to see those deductions we need the inverse mapping as well.

No. You should keep in mind that RDF statements will be imported (mapped)
into a RIF module/scope. Other RIF rules will query the info in that
module, but they will not add any rules to it. 

If somebody wants to modify the imported RDF theory, they should probably
create a different module. Certainly the above rule does not require the
reverse rules that feed # back into rdf:type.

> 
> > In this way, RDF's theory of subclasses is hooked into the minimalistic
> > RIF's theory. The translation should always be with respect to some
> > scope/module so the additional rif axioms will not affect other rule sets.
> > Applications written in RIF dialects will be able to easily navigate within
> > RDF.
> 
> I'm a little nervous of making modules an intrinsic part of the mappings 
> since I'm not sure how many systems other than Flora support modules.
> 
> > I did not understand what you wanted to say by "it would be preferable if
> > RDF and XML data models could be mixed in the same module" below. You seem
> > to imply that the current proposal prevents navigation within XML
> > literals. Why so?
> 
> In the RDF mapping the XML literal is an opaque data type. If we added 
> builtins for pulling apart that datatype then we could navigate within 
> the literal. I guess the current proposal doesn't rule out *also* having 
>   such builtins.

Of course it does not. We should come up with such builtins. Possibly based
on XPath or XQuery (my personal: XQuery is too heavy).


	--michael  


> Dave
> -- 
> Hewlett-Packard Limited
> Registered Office: Cain Road, Bracknell, Berks RG12 1HN
> Registered No: 690597 England
> 
> > 
> > 
> > 	--michael  
> > 
> > 
> >> Michael Kifer wrote:
> >>>> [On the telecon I started to raise the issue of why having separate type 
> >>>> and subclass modelling in RIF is problematic, especially for RDF/RDFS, 
> >>>> the discussion timed out and I took the action to clarify the issue in 
> >>>> email.]
> >>>>
> >>>> The core issue is that in RDF, RDFS and OWL/full the properties that 
> >>>> express model level relations (rdf:type, rdfs:subClassOf etc) are not 
> >>>> distinct from those that express instance level relations. There is no 
> >>>> metamodel/model/instance layering.
> >>>>
> >>>> Take a concrete example:
> >>>>
> >>>>     :Dave rdf:type :Person .
> >>>>     :Dave foaf:name  "Dave" .
> >>>>     :Person rdfs:subClassOf :Animal .
> >>>>
> >>>> In Jos's translation this would correspond to RIF Frames:
> >>>>
> >>>>     :Dave [rdf:type -> :Person, foaf:name -> "Dave"] /\
> >>>>                           :Person[rdfs:subClassOf :Animal]
> >>>>
> >>>> (I've omitted all the ".."^^rif:iri and stuck to curie format for IRIs 
> >>>> for clarity so this is not legal RIF syntax.)
> >>>>
> >>>> I presume from the discussion that if we accept the Classification 
> >>>> machinery then the translation would have to be modified to generate:
> >>>>
> >>>>     :Dave # :Person [foaf:name -> "Dave"] /\ :Person ## :Animal
> >>>>
> >>>> Now consider a RIF condition which asks for all the property values of a 
> >>>> specific object:
> >>>>
> >>>>     :Dave[?p -> ?v]
> >>>>
> >>>> With raw RDF this should match the example data with the binding sets:
> >>>>
> >>>>     { {p=foaf:name, v="Dave"} {p=rdf:type, v=:Person} }
> >>>>
> >>>> if I have enabled RDFS semantics then there should be a third binding:
> >>>>
> >>>>    { {p=foaf:name, v="Dave"} {p=rdf:type, v=:Person}
> >>>>                  {p=rdf:type, v=:Animal} }
> >>>>
> >>>> Whereas under the proposed semantics all I would get is:
> >>>>
> >>>>    { {p=foaf:name, v="Dave"} }
> >>>>
> >>>> Of course we could define # and ## to just be aliases for the frame 
> >>>> slots corresponding to rdf:type and rdfs:subClassOf. However, that 
> >>>> wouldn't be very helpful for people like Gary who want to use # and ## 
> >>>> to represent a Java or XML Schema data models.
> >>>>
> >>>> We could define the aliases as part of the RDF translation so that all 
> >>>> RDF datasets expressed in RIF would explicitly also include the 
> >>>> correspondence rules:
> >>>>
> >>>>    ?p[rdf:type -> ?t] :- ?p # ?t .
> >>>>    ?p[rdfs:subClassOf -> ?t] :- ?p ## ?t .
> >>>>
> >>>>    ?p # ?t :- ?p[rdf:type -> ?t] .
> >>>>    ?p ## ?t :- ?p[rdfs:subClassOf -> ?t] .
> >>>>
> >>>> But that strikes me as horrible.
> >>> First, I am not sure we need the second pair of axioms. But even if we do,
> >>> I do not see any problem here. Why is it horrible? You translate one theory
> >>> into another. The theory that you are translating into RIF may have its
> >>> peculiarities, which may require additional axioms. Why is RDF special so
> >>> that its translation should somehow not use axioms?
> >> It is only special in that it is defined by W3C as one of the 
> >> foundations of the semantic web, RIF is part of the semantic web 
> >> activity and our charter calls for us to define something which is RDF 
> >> compatible.
> >>
> >> Given enough mappings anything which is sufficiently computationally 
> >> complete could be claimed as RDF compatible - it is a judgement call how 
> >> natural and useful a given set of mappings is.
> >>
> >> In this case the mappings to # and ## seems to buy us little.
> >> We risk ending up with a nest of incompatible mappings. Gary, for 
> >> example, would likely implement #/## by mapping to Java classes and 
> >> would then be unable to translate rules like the above and would be 
> >> unable to work with RDF data. Not a problem for him right now but given 
> >> Oracle's investment in RDF and OWL it might be a problem in the future. 
> >> Yet there is no difficulty in using Oracle's rule engine to process RDF 
> >> data if it weren't for this seemingly artificial requirement to map 
> >> different class hierarchy concepts to the same #/## machinery.
> >>
> >>> Finally, none of the axioms are, in fact, necessary in the translation. You
> >>> can use your old translation. As we discussed, we need a module/scope
> >>> mechanism. An RDF KB can be embedded using your original translation into
> >>> some module, say module named foobar. Another module may query that RDF KB
> >>> using something like
> >>>
> >>> ?- ?o[rdf:type->?c]@foobar.
> >>>
> >>> or it may decide to "import" the RDF class hierarchy by adding a rule
> >>>
> >>> ?o:?c :-  ?o[rdf:type->?c]@foobar.
> >> That's a good point.
> >>
> >> Though it would be preferable if RDF and XML data models could be mixed 
> >> in the same module. RDF supports embedding of XML literals and a future 
> >> semantic web dialect of RIF may want to be able to express rules which 
> >> can navigate the internal structure of such literals within RDF data.
> >>
> >> Dave
> >> -- 
> >> Hewlett-Packard Limited
> >> Registered Office: Cain Road, Bracknell, Berks RG12 1HN
> >> Registered No: 690597 England
> >>
> >>
> > 
> > 
> > 
> 
>

Received on Tuesday, 31 July 2007 12:14:23 UTC