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

Christoph LANGE ch.lange at jacobs-university.de
Sat Jul 17 14:11:03 CEST 2010


Hi James,

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
* 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"/>
> >       <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.
> Why not also put <OMS cd="transc1" name="sin"/> here?

Maybe yes.  From an RDF point of view it doesn't make a difference anyway, as
the OCD→RDF "phrasebook" would simply discard objects attributed with
definitionURL and merely take the value of that attribution, resulting in the
RDF link

<http://www.openmath.org/cd/transc1#sin> owl:sameAs <http://dlmf.nist.gov/4.14.E1">

So the question we have to answer is "what looks best from a pure OpenMath
point of view?"  _The_ sin is already in the place where it should be, i.e.
it's the first argument of owl#sameAs above.  The second argument is merely
intended to be "the thing with the URI http://dlmf.nist.gov/4.14.E1".  If that
URI fit the cdbase/cd#name schema, we could simply give the second argument as
an <OMS cdbase="..." cd="..." name="..."/>.  But as the DLMF URIs don't fit,
we have to stow them away into attributions, and these attributions simply
needs something that carries them.

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

> > 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
of that function?  And would you then, after that review, let me know 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.) – Should I
create a Trac ticket for that?

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

Cheers,

Christoph

-- 
Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://openmath.org/pipermail/om/attachments/20100717/9d334cf4/attachment.pgp 


More information about the Om mailing list