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

[Christoph LANGE]

Hi Bruce,

2010-07-19 17:31 Bruce Miller <bruce.miller at nist.gov>:
> On 07/18/2010 09:47 AM, Christoph LANGE wrote:
> >  ...  Let http://dlfm.nist.gov/4.14.E1 be the
> > equation, and let http://dlmf.nist.gov/4.14.html#E1 be the materialization
> > (called "information resource" in the WWW jargon) of that equation in HTML.
> 
> An aside: I think I understand the points, and emphases
> you're trying to make here, but I'd like to discourage
> thinking of .../4.14#E1 as being deeply different
> from .../4.14.E1.  The former is simply the latter
> "in context".  And please leave off the ".html"

I should explain that I made this distinction as an attempt to disambiguate,
and the ".html" was intentional, even though you might not have any physical
files named *.html.

To avoid misunderstandings w.r.t. the current DLMF web infrastructure, let me
call those two things "sin-function" and "chapter4.html#sin-paragraph".

> [The rationale is somewhat more mundane than the
> discussion here, but I think worthwhile. We're
> trying to maximize the usefulness of links,
> permalinks, bookmarks, content negotiaion,
> electronic vs paper cross-referencing.]

You are already mentioning the buzzword "content negotiation", and that's in
fact what would be needed for linked data compliance.  You may already have
such plans for DLMF, but as that whole business was also hard to understand
for _me_ initially, let me recap it for the interested audience:

The idea is that there is an identifier for "the sin function", i.e.
"sin-function".  This identifier, also called "cool URI", denotes an abstract
entity about which we can make OMOBJ assertions and RDF statements in order to
describe/define it, but no material representation can be downloaded from the
"sin-function" URI, if treated as a URL.  This is called a "non-information
resource" in web terminology.

A well-behaved client that requests to download a concrete materialization of
something always declares the desired encoding.  Depending on what the client
requests from the "sin-function" cool URI, it gets redirected to the actual
materialization using HTTP 303.  E.g. when the client requests
application/xhtml+xml, it gets redirected to "chapter4.html#sin-paragraph" –
and to something else if it requests, e.g., application/rdf+xml.

> I don't know that I intentionally suggested that, or followed
> someone elses suggestion, but if such a URL were to
> become valid in the near term, it would probably just
> be a restatement of the informal notion of
> 4.14.E1 "defining" sine.  That is,
> http://dlmf.nist.gov/#sin would (currently) redirect to
> http://dlmf.nist.gov/4.14.E1 which would redirect to
> http://dlmf.nist.gov/4.14#E1

A plain redirect seems wrong to me, because that would give a client the false
impression that http://dlmf.nist.gov/#sin is somehow the same as
http://dlmf.nist.gov/4.14.E1.  When I used http://dlmf.nist.gov/#sin, I rather
meant the thing I called "sin-function" above, which would be owl:sameAs
http://www.openmath.org/cd/transc1#sin, and which would be related to
http://dlmf.nist.gov/4.14.E1 via relations (from weak to strong) such as
"occurs in", "is described by", or "is defined by".

> I would imagine that it is valid for the 1st and 2nd
> URI's in that list can reasonably be taken as
> _identifying_ distinct things (a definition of sine
> vs an equation, respectively).  The practicalities of
> a working web server could be confusing however.
> 
> Whether DLMF should provide an explicit URL indicating
> "sine itself", or it's definition ... or whether we
> should even think of ourselves as defining sine...
> is something this discussion can help answer.

I hope I got it a bit clearer now.

Cheers,

Christoph

-- 
Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701