[Mulgara-general] Error applying a KRule model to anexistingRDF model
Ghazzaoui, Ramez (NIH/NLM/LHC) [C]
ghazzaouir at mail.nih.gov
Fri Dec 12 14:07:28 UTC 2008
Sounds like that'll fix it! I will try this as soon as I get to my office. Thank you Paul. I really wish there were a language guide for writing KRules. Something other than the sample KRule file found on the web site. It looks like doing it with the RLog would be simpler, but still a language guide would be needed for novice users. However, as always, the forum is here to fill in the gaps and that's more than any user can really ask for :-)
-Ramez
________________________________
From: Paul Gearon [mailto:gearon at ieee.org]
Sent: Fri 12/12/2008 3:29 AM
To: Mulgara General
Subject: Re: [Mulgara-general] Error applying a KRule model to anexistingRDF model
On Fri, Dec 12, 2008 at 7:20 AM, Ghazzaoui, Ramez (NIH/NLM/LHC) [C]
<ghazzaouir at mail.nih.gov> wrote:
> I tend to agree with your conclusion that the error must find its roots
> in the Rules file. That's because the same setup works for all other
> things so I really doubt that this would be a setup/network error.
I don't know why the marshalling isn't working (and I'll have to fix
that), but yes, the real problem is the Krule file.
> Just FYI: The KRule file consists of a bunch of rules that are almost
> identical to each other (except for the string that each of them
> matches). The first and most logical way to start would be to leave one
> rule in place and eliminate all the others. I tried this, leaving in
> place only the rule for QualifierName, and I still get the error.
OK, I found the problem. I'm putting in more informative exceptions to
explain it when this happens.
You've referred to URI-References which are not pointing to anything
else. The is because Krule uses references to URIs and not the URIs
themselves.
To explain... RDF has had a back-room debate for some time about
whether certain assertions should be made on the URIs directly, on if
they should be made about nodes which in turn refer to the URIs. The
reason for the indirection in this case is because you don't want your
rules to inadvertently introduce assertions that change the properties
of the URIs of interest. It's mostly an academic point, but that's the
way it works.
To fix it up, you'll need to declare the URIReferences, along with
where they point to. So for instance, the first rule has:
<URIReference rdf:about="#hasDescriptorName"/>
I don't know what your domain is, as you never included it in your
file, but if you create an entity (at the top of the file) called
"krm", then you can refer to it this way:
<krule:URIReference rdf:about="#hasDescriptorName">
<rdf:value rdf:resource="&krm;hasDescriptorName"/>
</krule:URIReference>
Th introduces the URI of krule:hasDescriptorName, with an rdf:value of
krm:hasDescriptorName. You need to do this for EVERY URI in your file.
The other way to achieve the same thing is to create an RLog file, and
let RLog build the RDF/XML for you. The following RLog is equivalent
to your Krule file:
hasName(N,V) :- hasDescriptorName(N,V).
hasName(N,V) :- hasConceptName(N,V).
hasName(N,V) :- hasSemanticTypeName(N,V).
hasName(N,V) :- hasPreferredTermName(N,V).
hasName(N,V) :- hasQualifierName(N,V).
hasName(N,V) :- hasTermName(N,V).
hasName(N,V) :- hasSupplementalConceptName(N,V).
hasName(N,V) :- hasCASN1Name(N,V).
If you run RLog on this it will generate a Krule file that you use the
same as you've already been doing things.
By the way, your rule for hasSupplementalConceptName was duplicated. :-)
Regards,
Paul Gearon
_______________________________________________
Mulgara-general mailing list
Mulgara-general at mulgara.org
http://mulgara.org/mailman/listinfo/mulgara-general
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 6134 bytes
Desc: not available
URL: <http://lists.mulgara.org/pipermail/mulgara-general/attachments/20081212/24b1055c/attachment.bin>
More information about the Mulgara-general
mailing list