Hi James, 2010-07-17 13:04 Professor James Davenport <[email protected]>: > 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Om mailing list [email protected] http://openmath.org/mailman/listinfo/om
