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

[Bruce Miller]

On 07/19/2010 12:58 PM, Christoph LANGE wrote:
> 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.

Right; I figured that's what you were after.

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

Right; and to be explicit, http://.dlmf.nist.gov/4.14.E1
and http://dlmf.nist.gov/4.14#E1 would both ultimately
fetch the same resource as you specify with the
"chapter4.html#sin-paragraph" (in the URL sense),
but potentially _name_ different things (in the URI sense).

OTOH, there is currently no "sin-function" object visible
in DLMF.

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

That's what I meant about "confusing", below.
Note that currently #sin does nothing. But if
DLMF were forced too quickly to have "URI's that name sin",
that is the closest we could get.
Ie. those 2 uri's are different and name different things
(sin and an equation, respectively).  If they were
dereferenced, fetching the "concrete materialization"
in your terms, they may end up returning the same
resource.

Of course, this is folded into the general question
of how DLMF should support these efforts in general;
whether DLMF even needs a "sine object" and a URI
to reference it...

  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
>