Dear OpenMath, This is my first post to the OM list, so bear with me. I have a few comments about OpenMath and RDF integration.
(1) I've been thinking about this for a long time, but so far I haven't done anything about it. In 2009, I made a blog post about it: http://straymindcough.blogspot.com/2009/06/semantic-mathml.html in which I discuss the opposite direction (OM/SCMML to RDF) than we seem to be discussing here (RDF to OM/SCMML). That post was supposed to be a discussion, apologies to Christoph for not responding. (2) Identifier mappings have been, and always will be, nontrivial. We know all OMSymbols have a standard map to URI, and that any QName has at least 2 semi-common maps to a URI: {ns}/{local} and {ns}#{local}. Mapping from a URI to a QName is much easier, just look for / or # and reverse the process. Mapping a URI to an OMSymbols might be as simple as Christoph suggests, but this ignores URNs which do not have any / characters. I see two possible solutions to this: (3) special-case RDF, or (4) extend OM semantics to match SCMML3. (3) If we are going to treat RDF as a special case, then we should include all URIs traditionally associated with the rdf: and rdfs: prefixes with a single CD called 'rdf' (so we could use <OMS cd="rdf" name="type"/> without a nonstandard cdbase). Also, if there is any interest in my next suggestion (4), then I would recommend keeping literal_lang, literal_type (and only those two) in the 'rdf' CD, and move things like resource sets and value queries to a CD called 'rdf2' or something similar. I like the idea of literal_lang for encoding (@lang) and literal_type for encoding (^^type), but I would encourage more adventurous and pathological examples. I can come up with a few examples, such as when the subject/object appear more than once, etc. How would each graph be converted into OM? Do all graphs correspond do a set of OMATTRs? In my opinion, blank nodes should be treated differently, converting to values rather than references, but this cannot be done in the most general case because of repeated predicates and repeated objects. I don't have a general solution, but I look forward to hearing discussions on this. (4) In Strict Content MathML3, all OMSymbols can be written <math cdgroup="{cdgroup file associated with symbol's cdbase}" xmlns="..."><csymbol cd="{cd}">{name}</csymbol></math> so there is no mismatch there, but the csymbol element definition (even in the Strict Content profile) specifies an href attribute (and a definitionURL attribute in the full profile), which allows for encoding any URI as is. Semantically, this should also denote an OMSymbol, but how to do so is not obvious. Since OM has had 3-field semantics since the beginning, concatenating an OMSymbol's fields is not an option. Consider if special semantics are attached to the case when the cd attribute is specified, but is empty. Consider also modifying the section of the OM standard "Canonical URIs for Symbols" to the effect that if {cd} is empty, then the canonical URI for the OMSymbol is: URI = cdbase-value + name-value otherwise, {cd} is non-empty, and the canonical URI is constructed according to OM-2.0 and previous. The reverse direction could then make the assumption that it was constructed with a cdbase that ends in some non-NCName character, which can be used to split the URI into an OMSymbol. (5) Thank you for your time, and forgive any mistakes I might have made. Regards, Andrew Robbins On Thu, Mar 1, 2012 at 8:13 AM, Christoph LANGE <[email protected]> wrote: > Hi Ken, > > some more comments on the RDF CD now that I looked into it: > > I don't feel comfortable with the approach for representing RDF resource > URIs as strings. > > I agree that it may be useful to apply the rdf.resourceset operator to > more complex descriptions of RDF resources, and now that I see how it > works, I agree that OWL Manchester syntax is a reasonable approach, that > my initial Turtle suggestion is nonsense – but then maybe SPARQL might > be more appropriate, as it is pure RDF and doesn't require OWL. OTOH it > is a little less concise and less elegant than OWL Manchester. > > But let's talk about URIs of single resources. In the past I have > always advocated the approach of treating them as OpenMath symbols, as, > in fact, both are identified by URIs. > > This "just" (and this question is unanswered so far) creates the problem > that OpenMath prescribes a rather restricted URI syntax > (cdbase/cd#name), whereas RDF allows pretty much any URI. > > In many practical cases at least RDF hash URIs fit into the OpenMath > scheme, but it's not always intuitive to enforce splitting them into > OpenMath-style cdbase, cd and name components, and it does not always > result in valid names. > > Consider http://www.w3.org/1999/02/22-rdf-syntax-ns#type, which might > end up as <OMS cdbase="http://www.w3.org/1999/02"; cd="22-rdf-syntax-ns" > name="type"/>. > > It would be more idiomatic wrt. OpenMath to speak of <OMS > cdbase="something" cd="rdf" name="type"/>. > > In a non-standard extension (implemented as a part of the OMDoc > language, which can be considered a superset of OpenMath) I have > suggested binding CD names to RDF namespace URIs, i.e. here binding the > "CD name" "rdf" to the namespace URI > http://www.w3.org/1999/02/22-rdf-syntax-ns#. For background see > > @inproceedings{LK:MathOntoAuthDoc09, > author = {Christoph Lange and Michael Kohlhase}, > title = {A Mathematical Approach to Ontology Authoring and > Documentation}, > url = {http://kwarc.info/kohlhase/papers/mkm09-omdoc4onto.pdf}, > crossref = {MKM09}, > pages = {389--404}, > keywords = {conference,clange-phd}, > pubs = > {clange,mkohlhase,projects/krextor,projects/omdocbiblio,projects/docOnto}} > @PROCEEDINGS{MKM09, > year = {2009}, > month = jul, > booktitle = {{MKM/Calculemus} Proceedings}, > title = {{MKM/Calculemus} Proceedings}, > editor = {Jacques Carette and Lucas Dixon and Sacerdoti Coen, Claudio > and Stephen M. Watt}, > number = {5625}, > series = {LNAI}, > keywords = {conference}, > isbn = {978-3-642-02613-3}, > publisher = {Springer Verlag}} > > but I wouldn't take the position of recommending this as a best practice > for OM in general. If we'd like to unify OpenMath and RDF URIs we need > a different approach, and I have no idea what this could be. > > And another final question is whether (and if so, how) your CD allows > for representing complete RDF triples as OM objects – of maybe this is > not intended after all. > > Cheers, > > Christoph > > -- > Christoph Lange, Jacobs University Bremen > http://kwarc.info/clange, Skype duke4701 > > → SePublica Workshop @ ESWC 2012. Crete, Greece, 27/28 May 2012. > Deadline 29 Feb. http://sepublica.mywikipaper.org > → I-SEMANTICS 2012. Graz, Austria, 5-7 September 2012 > Abstract Deadline 2 April. http://www.i-semantics.at > _______________________________________________ > Om mailing list > [email protected] > http://openmath.org/mailman/listinfo/om _______________________________________________ Om mailing list [email protected] http://openmath.org/mailman/listinfo/om
