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 <[email protected]>: > 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Om mailing list [email protected] http://openmath.org/mailman/listinfo/om
