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

[Christoph LANGE]

Hi Bruce,

  thanks for your feedback.  Let me answer both of your mails at once.

2010-07-18 03:09 Bruce Miller <bruce.miller at nist.gov>:
> I don't think this is the assertion of equivalence
> that you want to be making.  The mathematical object
> associated with http://dlmf.nist.gov/4.14.E1 is an
> equation or relation

OK, so it rather corresponds to our FMPs.

> I understand that the goal is to formalize the
> mention of dlmf urls within CDs;
> is there a relation type more like "defines"
> that could be used? (or "satisfies", or...)

Good suggestion.  There is one more type of relation that is common in the
world of RDF linked data, which I haven't mentioned so far: rdfs:isDefinedBy
(a subrelation of rdfs:seeAlso) points to an authoritative definition of
something.  (Note that RDF(S) does not have a strong sense of mathematical
semantics, as, e.g., OMDoc, so where RDFS says "define", it rather means
"describe".)  I think that's the situation we have here, because we say in the
OM CDs that "the OM function F is defined according to A&S".  (If that's too
strong, but I think it isn't, http://purl.org/dc/terms/source might also be
appropriate, which points to something the subject has been derived from.)

> Can that not have a status such that if two resources
> employ a "sin" that is "defined by" http://dlmf.nist.gov/4.14.E1
> that they can be considered to be using the same "sin"?
> (this is what you're after, isn't it?)

rdfs:isDefinedBy would be too weak to support such conclusions.  If we
introduced a custom, stronger "defined by" relation, I would still be careful.
I could imagine an equation that defines two concepts at the same time, which
would of course not make them the same.  (OK, then those two concepts wouldn't
have the same name, e.g. "sin".)

2010-07-18 04:55 Bruce Miller <bruce.miller at nist.gov>:
> http://dlmf.nist.gov/4.14.E1 is the permalink to,
> and identifies, Equation 1 in Section 14 of Chapter 4.
> It corresponds to equation 4.14.1 in the (print) handbook.
> 
> ...
> 
> Other than that, http://dlmf.nist.gov/4.14.E1 is
> certainly not "sin", but might be taken as the definition
> of it.  That does raise another interesting question.
> 
> Currently, we've established "definitions" for
> all the important functions in an informal way;
> the primary purpose is to have a main entry point
> where a reader can find clarification about what "xyz" is.

Let me elaborate on that.  A URI like http://dlmf.nist.gov/#sin, as you
suggested, could become the actual entry point for "sin" in future.

> As such, there is currently no real permanence as to
> which object (which may be an equation and/or text!)
> defines a function; in the future, with edits, a
> different location may server as a better (informal)
> definition.
> 
> Does a formal and/or permanent "defining equation or
> passage" really need to be established by & within DLMF?
> I suspect that could be both tricky and controversial
> in many cases!  Sometimes there are several reasonable
> choices for the "definition" (eg. DE's vs explicit
> expansions vs...).

But I would rather imagine such an entry point as a node in an RDF-like graph,
with multiple outgoing edges.  I.e. DLMF would have _the_ sin function, but
then two or more links to "defining equations".

> I suppose that an issue here is that these different definitions potentially
> define different functions, although the goal of a work like DLMF is to
> hammer on them until they _are_ the same!
> 
> Short of specific document objects being taken as "definitions" it is
> certainly safe to say that sin must "satisfy" ../4.14.E1 or a variety of
> other things.  I'd find "see also" as deeply unsatisfying :>

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/20100718/6a72d19a/attachment.pgp