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

[Christoph LANGE]

Hi Urs, hi Bruce (there's an important question to you in this mail),

  you raise a valid point.  In fact, from a strict "RDF Linked Data" point of
view, DLMF is not (yet) the most suitable target to link to, as it does not
properly distinguish "the sine function" from "the page describing the sine
function".  Or does it?  We should ask Bruce.

My motivation for pushing links from the OpenMath CDs to DLMF is mainly that
this use case makes a lot of sense, as we already have that information (as
natural language reference to the A&S book) in the CDs, so why not expose it
to machines?  We wanted to provide some links from the (HTML-rendered) CDs to
relevant related resources anyway, and I'd rather like to do this by putting
the links into the CDs instead of e.g. putting them into a proprietary file
that only our OCD→XHTML XSLTs understand.

I consider it more of a temporary problem that the DLMF does not yet expose
its content as machine-readable linked data.  (If we get this properly started
on openmath.org, which is not too hard, that might convince DLMF of following
us.)

2010-07-17 19:04 Urs Holzer <urs at andonyar.com>:
> One other thing that strikes me here: in linked data practice one often 
> makes a distinction between a resuource and its description. (Is this 
> correct, Christoph?) So, It hink that <http://dlmf.nist.gov/4.14.E1> is 
> a description of a resource 'sin', not the 'sin' itself. (Or does DLMF 
> say that <http://dlmf.nist.gov/4.14.E1> is the resource and 
> <http://dlmf.nist.gov/4.14#E1> is the description?) If I am right, using 
> owl:sameAs might cause trouble. For example, 
> <http://dlmf.nist.gov/4.14.E1> might have an author:
> 
>   <http://dlmf.nist.gov/4.14.E1> dc:author "Levinson" .

@Bruce, direct question to you:  There seem to be two ways to address a
definition in the DLMF: 4.14#E1 (@David, this would BTW give us a nice OMS,
but I'm afraid this is not the URL/URI that we want) and 4.14.E1.  It this
difference intended?  And if so, what do those two URLs/URIs mean?

To me, 4.14#E1 seems to be a paragraph on a page, whereas the (i) popup calls
4.14.E1 a "permalink", which suggests to me that this might be a persistent
identifier for an object, and we might call that object "the definition of the
sin function", or probably "the sin function".  

FYI, DLMF served in a linked data compliant way would behave as follows.
Suppose 4.14.E1 is the identifier of the function.  Then, a client requesting
that URL as HTML would not immediately be served the page, but instead get a
303 redirect to 4.14#E1, which is a linked data server's way of saying "I
can't deliver the function to you, but a concrete (HTML) _description_ of the
function, and you will find that when you ask me for 4.14#E1".  See
http://www.w3.org/TR/cooluris/ for background info.

> This would then cause the 'sin' itself to have Levinson as author which 
> is kind of weird. In general, I think one has to be extremely careful 
> when using owl:sameAs. I opt for not using owl:sameAs and not using 
> relation1#eq either. Is there another option which would be reasonable 
> in practice?

rdfs:seeAlso is then the only practical relation, …

> Maybe it would be correct to state that <http://dlmf.nist.gov/4.14.E1> 
> _defines_ 'sin' instead of saying that they are the same.

… or, then, maybe a custom om:isAlsoDefinedBy (which would be a subproperty of
rdfs:seeAlso), or something from SKOS, but I'm not sure how many existing
tools would support that.

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/2c4c583c/attachment.pgp