[Om] Intgraging OM with RDF [was: How to translate csymbol/@definitionURL]
Michael Kohlhase
m.kohlhase at jacobs-university.de
Sun Jul 18 13:35:54 CEST 2010
Dear all,
I have been traveling for a couple of days, and spent some time making
sense of the discussion so far. I think that the goal behind all of this is
(*) OpenMath CDs can interoperate with the Semantic Web and OM can act as a
"Semantics Provider for the Maths on the Semantic Web".
I consider this as an important goal for OpenMath, and am delighted with
the discussion.
However, from what I see, there seem to be three (largely independent)
topics concerning the OM/SemWeb integration that are discussed together
that I would like to tease apart for clarity
1. Extracting RDF from OpenMath CDs as a service for the Semantic Web
2. Injecting objects from the Semantic Web into OpenMath
3. The DLMF is possibly not Semantic-Web compliant.
In particular, it seems that neither of them really has anything to do
with the cd/name/cdgroup vs URI discussion, which only came in because
Christoph had a particular implementation in mind.
Now, let me comment on these three topics in order.
1. If we can extract RDF from OCDs, then we have a way to meet (*). I
personally think that CLs last suggestion of adding *.rdf files to
*.ocd files (just like *.sts *.ntn, ...) is closest to the
OpenMath tradition here. I would suggest to open a new thread (or
TRAC ticket) that concentrates on getting the right technically,
how to author it, and how to get a process going that will add
this information for the CD set we have so far.
I really think that the "auxiliary file" approach is the right one
for OCD here; all who like a more integrated approach can use what
Christoph has developed for OMDoc CDs, there is no need to make
the two approaches syntactically similar.
2. If we can represent non-OM objects (e.g. math concepts from the
DLMF) in OpenMath, then we can use FMPs to represent properties of
these (and in particular relations to OCD-defined objects). From
these we could then generate RDF to achieve (*). This solution
would additionally open up the reasoning about non-OM objects in
OpenMath tools and thus would put OM on an equal footing with the
Semantic Web, so we should pursue it.
There seem to be two possible solutions to this on the table.
1. *CD-based*: particular sets non-OM objects are reflected in
special CDs (e.g. for the DLMF objects a "dlmf" cd).
2. *Meta-CD-based*: we develop a meta-CD that supplies a symbol
that makes an OM object out of a OMSTR argument.
The second one seems more general to me, since we can always make
special-case CDs that use OM relations on OMSTR-based objects.
3.seems to be be independent of these two, and seems to be making
progress independently.
Maybe this can bring some structure into this discussion.
Michael
On 16.07.10 12:52, Christoph LANGE wrote:
> Hi David,
>
> let me turn this topic into a new thread and answer the rest separately.
>
> 2010-07-16 11:30 David Carlisle<davidc at nag.co.uk>:
>> On 15/07/2010 23:07, Professor James Davenport wrote:
>> > Q. Why was DefinitionURL deprecated in MathML (by declaring it to be
>> > pragmatic-only).
>>
>> the notes don't record who asked the question,
> that was me, …
>
>> but it's not deprecated (you can't deprecate something that was never there)
>> the attribute isn't in Strict MathML because it isn't in OpenMath.
> … and I interpreted it as a de facto "deprecation" because from a
> content-oriented point of view my impression is that new tools will rather use
> strict CMML, whereas pragmatic CMML was rather kept for historical and
> political reasons. So from that point of view anything that is not
> expressible in strict CMML seems deprecated to me. But that objection was
> based on the wrong assumption that definitionURLs that don't fit into the
> CDBase/CD/Name schema wouldn't be expressible at all in strict CMML.
>
> Note that I was not concerned about the @definitionURL _attribute_. It is
> perfectly clear to me that strict CMML has the CD/name syntax to express the
> same, but my point was that CD/name cannot express the same as @definitionURL.
>
> Once you start thinking about linking OpenMath CDs to other datasets using
> URIs (e.g. the DLMF, Paul's notation census, DBpedia, etc.), see my OM
> workshop talk on Linked Data, there will be URIs that don't fit into the
> CDBase/CD#name schema.
>
> Suppose we want to say: transc1#sin is the same as
> http://dlmf.nist.gov/...#sin, and suppose we want to say: the notation census
> entries for transc1#sin are at http://wiki.math-bridge.org/...#sin. OpenMath
> does not really have a way of "linking" to things, but I think we _could_
> introduce arbitrary links into OpenMath via a relaxed interpretation of FMPs,
> or probably via attributions. I.e. we wouldn't be forced to enhance the
> syntax of OpenMath CDs by something RDF-like.
>
> <FMP>
> <OMOBJ>
> <OMA>
> <OMS cd="relation1" name="eq"/>
> <!-- or take e.g.<OMS cd="owl" name="sameAs"/>, which is more
> common in the Linked Data world -->
> <OMS cd="transc1" name="sin"/>
> <OMS cdbase="http://dlmf.nist.gov" cd="..." name="sin"/>
> </OMA>
> </OMOBJ>
> </FMP>
>
> <FMP>
> <OMOBJ>
> <OMA>
> <OMS cd="..." name="has-notation-census-entry"/>
> <!-- or take e.g.<OMS cd="rdfs" name="seeAlso"/>, which is more
> common in the Linked Data world but has a very weak semantics -->
> <OMS cd="transc1" name="sin"/>
> <OMS cdbase="http://wiki.math-bridge.org" cd="..." name="sin"/>
> </OMA>
> </OMOBJ>
> </FMP>
>
>
>> MathML DefinitionURL in general (if it doesn't point to a CD)
>> corresponds to an OpenMath annotation using a symbol "definitionurl" in
>> some CD and a OMstring to hold the URI.
> Aha! I wasn't aware of that. But this is specified nowere in the MathML 3
> spec, is it? My understanding was that pragmatic CMML is not more expressive
> than strict CMML, i.e. that for everything you can express in pragmatic CMML
> there is a well-defined translation to strict CMML somewhere in the spec.
> Otherwise human guesswork would be involved, and that would kill
> machine-understandability.
>
> And how would it work? You can only attribute something that is
> an OpenMath object, so how would you say "this is something that has a
> definitionURL"?
>
> <csymbol definitionURL="http://cdbase/cd#name"/> translates to
> <OMS cdbase="http://cdbase" cd="cd" name="name"/>
>
> but what does<csymbol definitionURL="http://example.org/foo/bar"/> translate
> to? (Note again that a lot of such #-less URIs exist out there, for good
> reasons)
>
> <OMATTR>
> <OMATP>
> <OMS cd="..." name="definitionurl"/>
> <OMSTR>http://example.org/foo/bar</OMSTR>
> </OMATP>
> <!-- WHAT GOES HERE? A dummy OMS, an OMV, ...? -->
> </OMATTR>
>
>> In the case that the definitionurl is of the form uri-of-cd#symbolname then
>> it just corresponds to the usual OMS cd=... name=... attrbutes.
> Always? Suppose we have a "see-also" link to
> http://en.wikipedia.org/wiki/Exponential_function#Formal_definition. That
> fits into the schema and could be linked to using
> <OMS cdbase="http://en.wikipedia.org/wiki" cd="Exponential_function"
> name="Formal_definition"/>, but that might give a system the false impression
> that http://en.wikipedia.org/wiki/Exponential_function has the semantics of an
> OpenMath CD, which it has not. So we might express such links differently,
> e.g. using the above-mentioned attribution.
>
> But then, if we treat some a/b#c URIs as links to OpenMath CD symbols, and
> others not, then we'd need some way to decide whether a given a/b#c URI is a
> CD symbol or not.
>
> Cheers,
>
> Christoph
>
--
----------------------------------------------------------------------
Prof. Dr. Michael Kohlhase, Office: Research 1, Room 62
Professor of Computer Science Campus Ring 1,
Jacobs University Bremen D-28759 Bremen, Germany
tel/fax: +49 421 200-3140/-493140 skype: m.kohlhase
m.kohlhase at jacobs-university.de http://kwarc.info/kohlhase
----------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openmath.org/pipermail/om/attachments/20100718/7aa38bf8/attachment.htm
More information about the Om
mailing list