Hi Andrew, thank you for your extensive reply.
> (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. I've stumbled upon your post some time ago but missed somehow to join the discussion. We've also created an ontology for representing mathematical expressions as RDF. For this reason we simply mapped the existing OM constructs to OWL classes and properties: Ontology: <http://numerateweb.org/vocab/math> ObjectProperty: attributeValue ObjectProperty: body ObjectProperty: variables ObjectProperty: binder ObjectProperty: arguments ObjectProperty: attributeKey ObjectProperty: target ObjectProperty: symbol DataProperty: encoding DataProperty: value DataProperty: name Class: Object Class: Application SubClassOf: arguments only ObjectList, symbol exactly 1 owl:Thing, Compound, arguments max 1 owl:Thing, symbol only Symbol Class: Attribution SubClassOf: arguments only AttributionList, target only Object, target exactly 1 owl:Thing, Compound, arguments max 1 owl:Thing Class: Binding SubClassOf: body only Object, binder only Object, variables only VariableList, variables max 1 owl:Thing, binder exactly 1 owl:Thing, Compound, body exactly 1 owl:Thing Class: Compound SubClassOf: Object Class: Foreign SubClassOf: encoding exactly 1 rdfs:Literal, encoding only xsd:string, Object, value only rdf:XMLLiteral, value exactly 1 rdfs:Literal Class: Literal SubClassOf: Object, value exactly 1 rdfs:Literal Class: Symbol SubClassOf: Object Class: Variable SubClassOf: name exactly 1 rdfs:Literal, name only xsd:string, Object Class: AttributionPair SubClassOf: attributeValue exactly 1 owl:Thing, attributeKey exactly 1 owl:Thing, attributeValue only Object, attributeKey only Symbol This ontology enables us to represent arbitrary OM objects as RDF. The basic idea is mainly the same as yours despite the fact that we've introduced classes for Applications, Bindings, Attributions, etc. Your example <m:apply> Symbol Content* </m:apply> [] sm:apply Symbol ; sm:applyTo LIST(Content) would be represented in our ontology as @prefix nw: <http://numerateweb.org/vocab/math#> [] a nw:Application ; nw:symbol Symbol ; nw:arguments LIST(Content) which is almost identical since we both used a "verbatim" mapping of SCML/OM to RDF. This approach has the advantage that it is easy to convert between SCML/OM and RDF. The drawback is that the specification of allowed argument types for applications (comparable to OM STS) is a bit complicated. If we have for example plus a nw:Symbol we could implement type checking by (with Manchester syntax) PlusApplication owl:equivalentClass "nw:symbol value plus" PlusApplication rdfs:subClassOf " nw:arguments only (rdf:first some NumericValue and rdf:next some (rdf:first some NumericValue)) " Another approach could be to make "plus" a subclass of Symbol that would allow us to attach the restrictions directly to "plus" instead of introducing the helper class "PlusApplication". > (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. I would prefer treating RDF as a special kind of math expression which is exactly what the "resource" symbol from the RDF CD http://www.openmath.org/cd/contrib/cd/rdf.xhtml#resource does: rdf.resource("<http://example.org/persons#Alice>") rdf.resource("foaf:Alice") rdf.resource("urn:myscheme:Material") The advantage of this approach is that it does not break existing OM vocabulary and allows us to stick with numbers and strings for primitive types (without introducing e.g. a special type for IRIs). Also Tools like text editors (e.g. Popcorn based) or graphical formula editors (Mathdox formula editor) are immediately enabled to work with RDF. > (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). I don't know if it's a good idea to mirror existing RDF definitions in OpenMath. Future OpenMath tools that are RDF-aware should be enabled to interpret external RDF resources (ontologies) and their definitions. > [...] > 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. Christoph asked a similar question. Maybe it is possible to reuse the vocabulary of "set1" and "relation1" for this task: set1.in("This is a comment.", rdf.valueset("rdfs:comment", rdf.resource("foaf:Person"))) relation1.eq(rdf.value("rdfs:comment", rdf.resource("foaf:Person")), "This is the only comment.") Blank nodes could be either referenced by their ID as rdf.resource("_:node0815") or they can be converted into a set of statements using the technique mentioned above. > [...] > 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 This seems like a viable solution. I think that an even better solution for the OpenMath XML serialization could be to get rid off the CDBASE definitions and simply use standard xmlns declarations for this task: <OMA xmlns:set1="http://www.openmath.org/cd/set1#";> <OMS name="set1:in" /> ... </OMA> This approach is also used by RDFa and works very well. > Thank you for your time, and forgive any mistakes I might have made. I also have to thank for your time and your valuable comments on this topic. Best regards, Ken _______________________________________________ Om mailing list [email protected] http://openmath.org/mailman/listinfo/om
