[Om] Adding DLMF links to CDs [Re: How to translate csymbol/@definitionURL]

[Professor James Davenport]

On Sat, July 17, 2010 1:11 pm, Christoph LANGE wrote:
> 2010-07-17 13:04 Professor James Davenport <jhd at cs.bath.ac.uk>:
>> On Fri, July 16, 2010 10:58 pm, Christoph LANGE wrote:
>> Can we just check on the methodology first? I stringly suspect the
>> answer is YES once that's sorted out, though.

> Of course, that's what I intended with my mail.  I see that two issues
> still need clarification:
> * what to use as the carrier of definitionURL attributions
As you pointed out, it doesn't MUCH matter, because the key line is the
one I've flagged below, but I agree with you it might as well be the OMS.
> * what "equivalence" relation to use
>
>> >   <OMOBJ xmlns="...">
>> >     <OMA>
>> >       <OMS cdbase="http://www.w3.org/2002/07" cd="owl" name="sameAs"/>
>> >       <OMS cd="transc1" name="sin"/>                <--- key line
>> >       <OMATTR>
>> >         <OMATP>
>> >           <OMS cd="mathmlattr" name="definitionURL"/>
>> >           <OMSTR>http://dlmf.nist.gov/4.14.E1</OMSTR>
>> >           <!-- this is the link, ... -->
>> >         </OMATP>
>> >         <OMV name="sin"/> <!-- ... the variable is just a dummy -->
>> I'm not sure I like this: sin isn't normally an OMV. We are talking
>> about THE sin, not just anything called sin.
> But I agree that the best candidate for that "carrier" would be <OMS
> cd="transc1" name="sin"/> here.
>
> (I just made this lengthy recap once more to emphasize that the carrier is
> not semantically relevant for the link to DLMF.)
Fiar comment.
>> > What kind of equivalence relation do we want to have?  The OpenMath
>> > functions
>> These functions - yes. I would want to doublecheck that
>> (I am down to review DLMF for CR anyway, so that's a necessary task).
>> While A+S/DLMF is veyr valuable, an OpenMath definition is logically a
>> separate assetion.
>
> OK, what does that mean for the annotation of the CDs with links to DLMF?
> Are
> you going to check for each CDDefinition that currently says "... as in
> A&S section ..." whether its FMPs correspond with the A&S (resp. DLMF)
> definition
I have already checked the A+S ones:
Corless,R.M., Davenport,J.H., Jeffrey,D.J. & Watt,S.M.,
According to Abramowitz and Stegun.
SIGSAM Bulletin 34(2000) 2, pp. 58-65.
> of that function?  And would you then, after that review, let me know
That's the plan.
> where I can set links to DLMF and where not?  (Note that we can, if we
> want, always
> set links using the semantically weaker rdfs#seeAlso link type.)
Good point.
> Should I create a Trac ticket for that?
Might as well.
>> > are intended to be the same as the DLMF ones.  We could express that
>> > in the OpenMath way using relation1#eq (Is that applicable to
>> > functions?), or
>> Yes, in the extensional sense - two functions are the same if they
>> always give the same results.
>> > using owl:sameAs, which is more widely understood by RDF-based linked
>> > data clients.
>> > The latter would become relevant once we start serving the OpenMath
>> CDs as
>> > RDF in addition to OCD and XHTML.
>> That's a very good question. I have slight doubts about relation1#eq
>> since
>> we're comparing an OpenMath object to something that isn't one, but this
>> may be an ill-founded objection.
>
> No, it's a very good objection.  I cannot tell you what implications it
> has to
> link two URIs with relation1#eq, but I can tell you what it means to an
> OWL reasoner when you use owl#sameAs (see
> http://events.linkeddata.org/ldow2010/papers/ldow2010_paper09.pdf for
I don't atcually feel much enlightened after reading that, but still.
> further
> background).  Please allow me a short excursion into OWL and OWL/RDF-based
> linked data here:
>
> Suppose the OWL reasoner already knows some facts about the source of the
> link
> (here: transc1#sin), such as (in terms of my ontology for OpenMath CDs,
> prefixed "om" here):
>
> <transc1#sin> rdf:type om:SymbolDefinition .
> <transc1#sin> dc:description "This symbol represents ..." .
> <transc1#sin> om:hasProperty <id-of-some-FMP> .
> ...
>
> Then, <transc1#sin> owl:sameAs <http://dlmf.nist.gov/4.14.E1> would imply:
>
> <http://dlmf.nist.gov/4.14.E1> rdf:type om:SymbolDefinition .
> <http://dlmf.nist.gov/4.14.E1> dc:description ...
>
> That means, <http://dlmf.nist.gov/4.14.E1> _is_ transc1#sin, with all of
> its
> properties.  The representation of transc1#sin at the URI
> <http://dlmf.nist.gov/4.14.E1> just happens to be encoded differently,
> i.e.
> not in the OCD format, and it needs not explicitly declare the same
> properties
> as we do in the CD (i.e. on the DLMF site there don't have to be the same
> examples as in the CD), but still it means the same.
>
> OWL reasoners make an open world assumption, so transc1#sin and
> <http://dlmf.nist.gov/4.14.E1> having the same properties does not
> necessarily
> lead to a conflict.  (Suppose <http://dlmf.nist.gov/4.14.E1> had another
> dc:description – that's possible, because it's said nowhere that things
> must
> at most have one dc:description.)  It would only conflict if the two
> things
> had properties that have explicitly been declared incompatible with each
> other
> in the respective ontologies declaring them.  (Note that DLMF isn't even
> semantically annotated ATM, but as a human I don't see any obvious
> conflicts
> there, and your review should settle the question whether the
> CDDefinitions are the "same as" the DLMF entries.)
>
> So much for the strict semantics of that.  You may now think that
> owl:sameAs
> is a bit too strong for us, but linked data practice (e.g. the application
> that I showed at the workshop) is more relaxed than OWL theory.  And there
> is
> not a big choice of link types that are universally understood by linked
> data
> clients.  The only alternative would be rdfs:seeAlso, which is IMHO too
> weak
I think I agree with you. But the IN MY VIEW (not necessarily the same as
Hayes-Halpin) asserting owl:sameAs is not something to be done lightly,
but requires the sort of check I am proposing to do.
> for what we want to say here, or an OpenMath-specific subrelation of
> rdfs:seeAlso (e.g. om:equivalentDefinition), but the average client will
> either ignore such links (i.e. not follow them), or treat them in the same
> way as rdfs:seeAlso.
>
> So I'd still opt for owl:sameAs (unless we want relation1#eq).
Where this check has been done, and comes up OK, then I agree with you.

James Davenport
Lecturer on XX10190, CM30070, CM30078/50123, CM50209
Hebron & Medlock Professor of Information Technology, University of Bath
OpenMath Content Dictionary Editor and Programme Chair, OpenMath 2009
IMU Committee on Electronic Information and Communication
Council of the British Computer Society
Federal Council, International Foundation for Computational Logic