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

I'm a little confused by the below discussion: surely if I am
interchanging PR based on say an XML/XSD data model, I would not be
editing rules in RIF format anywhere? The real issue is: does it make
sense to map from a static-typed-data-model to a dynamic-typed-model and
back again during a RIF interchange transaction between 2 PR systems as
part of an XML document+rules interchange? For sure one "problem" would
be that I will have some XML data structure alongside some rules which
may not be readily "readable" against the data (eg for a contract
exchange use case). This affects usability IMHO. 

> 
> Gary Hallmark wrote:
> 
> > Dave Reynolds wrote:
> >
> >>>> 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]
> >>>>
> >>>>    ?p # ?t :- ?p[rdf:type -> ?t] .
> >>>>    ?p ## ?t :- ?p[rdfs:subClassOf -> ?t] .
> >>>>
> >> In this case the mappings to # and ## seems to buy us little.
> >
> > In a way I agree, but only because I would like static declarations
such
> as
> >
> > FrameType Person##Animal [ name -> xsd:string ]
> >
> > I'm not sure I can use the rules above because I need to extract the
> > 'business data model" from the RIF document before I can translate
the
> > rules.  All this occurs at translation time, which is before the
rules
> > are executed.
> 
> Yes. There is a fairly fundamental difference between strong
statically
> typed systems and weak or dynamically typed. If you need a RIF dialect
> with static typing and want to use #/## for that then you will need a
> different interpretation of # and ## than anyone who might, for
example,
> want to infer isa or sub relationships for whatever reason.
> 
> I guess this is a core question for the RIF PRD sub-group, are all
> relevant PR systems statically typed and is static typing in RIF be
> necessary for efficient translation?
> 
> >> We risk ending up with a nest of incompatible mappings. Gary, for
> >> example, would likely implement #/## by mapping to Java classes
> >
> > yes
> >
> >> and would then be unable to translate rules like the above
> >
> > the problem seems to be that without static declarations I need to
run
> > the rules in order to translate the data model that I need in order
to
> > translate the rules...
> >
> >> 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.
> >
> > I have to disagree.  RDF poses great difficulty because of the
> > difficulty in extracting a static declaration like the one above.
> 
> OK, this is somewhat off the main topic, my fault for making the
> comment. Let me respond briefly but perhaps we should chat about it
over
> a beer at the next f2f rather than weigh down the list too much.
> 
> > Our
> > UI tools require a data model so that rules can be phrased in
structured
> > English like
> >
> > IF *Person.name* = "Dave"
> > THEN ...
> >
> > Items marked with *stars* are pick lists in the UI that are driven
off
> > the data model.
> > Without a static data model, I'd have to have something generic like
> >
> > IF  *Frame.property1* =  "rdf:type" and *Frame.value1* = ":Person"
and
> > *Frame.property2* = "foaf:name" and *Frame.value2* = "Dave"
> > THEN
> >
> > This latter mess is unsuitable for a business user (or for me, for
that
> > matter).
> 
> Sure, though this is confusing the UI and rule authorship issues with
> the rule engine issues.
> 
>  From the engine point of view the RDF data model is static (there are
> just triples and nodes, triples have three fields etc). So if there
were
> a reason to do so you could have a generic RDF data model in Java and
> write rules over that. That's basically what you would need to do
anyway
> to implement the untyped Frames (not Classifications) in the current
RIF
> draft.
> 
> Whilst your group might have no interest in that right now, it is not
> completely irrelevant to Oracle. Oracle are certainly selling RDF/OWL
> support at the moment and are actively promoting use of RDF rules for
> data integration in an enterprise setting [1]. It just seems at least
> plausible that since you have two rule engines then one day someone
> (perhaps a customer) might want them to interoperate via RIF :-), and
> one of those rules engines is currently used to process RDF data.
> 
> > IMHO, the lack of an explicit static data model for RDF makes it
hard to
> > build UI tools, and without good UI tools you aren't going to get
far in
> > the business software marketplace.
> 
> Humm.
> 
> On the one hand I agree with you that open extensible data models do
> raise UI challenges and there are innovations to be made in that area.
> 
> However, in practice people do often work within the confines of
> particular vocabularies, expressed via RDFS or OWL ontologies. So you
> can have UI tooling that allow you to pick from terms in your current
> active vocabularies. The difference is that in a semantic web setting
> users expect to be able to load in new ontologies or extend existing
> ones. Good UIs for that are not trivial but nor are they impossible.
> 
> Certainly several commercial OWL editors have quite usable UIs and
> permit manipulation of RDF instance data.
> 
> Dave
> 
> [1]
>
http://www.oracle.com/technology/tech/semantic_technologies/pdf/semantic
11
> g_dataint_twp.pdf
> 
> --
> Hewlett-Packard Limited
> Registered Office: Cain Road, Bracknell, Berks RG12 1HN
> Registered No: 690597 England

Received on Thursday, 26 July 2007 17:59:43 UTC