We report about a complete redesign of the tools and data of the SymbolicData project according to RDF technologies and Linked Data principles that proved to be powerful within modern semantic web approaches. During that redesign the focus of the project changed from a mere data store towards the vision of a Computer Algebra Social Network (CASN) to support technically intercommunity communication between Computer Algebra subcommunities. In the last part of the paper we describe ongoing e orts to implement a technical basis for a Distributed Semantic Social Network infrastructure to run such a CASN.
The SymbolicData project grew up from the Special Session on Benchmarking
at the 1998 ISSAC conference to continue the e orts started by the PoSSo [
There was almost no advance during 2002{2005. In a second phase around 2006 the project matured again and extended its scope. Data was supplied by the CoCoA group (F. Cio ), the Singular group (M. Dengel, M. Brickenstein, S. Steidel, M. Wenk), V. Levandovskyy (non commutative polynomial systems, G-Algebras) and R. Hemmecke (Test sets from Integer Programming). In 2005 the German Fachgruppe Computeralgebra launched the Web site http: //www.symbolicdata.org. During the Special Semester on Grobner Bases (GB) in March 2006 we tried to join forces with the GB-Bibliography project (B. Buchberger, A. Zapletal) and the GB-Facilities project (V. Levandovskyy).
In 2009 we started to refactor the data along standard Semantic Web concepts
based on the Resource Description Framework (RDF). We completed a redesign
of the data along RDF based semantic technologies, set up a Virtuoso [20] based
RDF triple store and SPARQL endpoint at http://www.symbolicdata.org as
an Open Data service along Linked Data standards [
One of the main decisions within that redesign process was a non-technical
one { leave the focus on data storage and the \roots" within the Polynomial
Systems Solving CA subcommunity in favour of stronger social interlinking. We
reshaped the SymbolicData Project as intercommunity project, that addresses
needs of subcommunities within the Symbolic Computation community to
prole, test and benchmark implementations as a cross cutting activity 1, and started
to develop links to other intercommunity activities as sagemath [
In section 2 and 3 we describe the current SymbolicData infrastructure in more detail. The rest of this paper addresses conceptual and practical problems, experiences and solutions towards a semantic-aware Computer Algebra Social Network as an intercommunity project.
Acknowledgement: This and ongoing work was realised within a project
Benchmarking in Symbolic Computations and Web 3.0 supported by the
Saxonian E-Science Initiative [
Our basic resources (examples for testing, pro ling and benchmarking software and algorithms from di erent areas of symbolic computation) are publicly available in XML markup, meta data in RDF notation both from a public git repo, hosted at http://github.org/symbolicdata, and from our remote RDF triple store at http://symbolicdata.org/Data. Moreover, we o er a SPARQL endpoint [18] to explore the data by standard Linked Data methods.
The website operates on a standardized installation using an Apache web
server to deliver the data, the Virtuoso RDF data store [20] as data backend, a
SPARQL endpoint and (optionally) OntoWiki [
The distribution contains also tools and prototypical solutions for a local
compute environment as, e.g., provided by Sagemath [
2 Tested with Linux Debian and Ubuntu 12.04 LTS standard distributions; a more detailed description can be found in the SymbolicData wiki [17].
We follow a development process along the Integration-Manager-Work ow Model3. This makes it easy to join forces with the SymbolicData team: Fork the repo to your github account, start development and send a pull request to the Integration Manager if you think you produced something worth to be integrated into the upstream master branch. Even if your contribution is not pulled to the upstream, people can use it, since they can pull it from your github repo to their github repo. This allows even for agile common small feature development { a widely practised way to advance projects hosted at github.com. You are encouraged to start a discussion about your plans early in the process and regularly report your progress on the SymbolicData mailing list.
Currently the SymbolicData data collection contains resources from Polynomial Systems Solving (390 records, 633 con gurations), Free Algebras (83 records), G-Algebras (8 records), GeoProofSchemes (297 records) and Test Sets from Integer Programming (28 records). These resources are stored in a at XSchema based XML syntax developed within SymbolicData version 2 that uses well established intracommunity syntaxes for the internal data. 3
Note that RDF provides a strong conceptual distinction between resources (basic information) and resource descriptions (meta information) and with SymbolicData version 3 we use XML representations more concisely to focus on the basic information structure itself.
Since the basic information is provided by di erent CA subcommunities it is a good advice to use the (textual) syntactical notations well established within a subcommunity to store data. In most cases such syntactical notations are not XML based, so one cannot use a standard XML parser to parse the internal textual representations \out of the box".
Since the subcommunity has plenty of parsers and tools at hand to input textual representations into their semantic-aware tools this is not a real obstacle in practise. In particular, in the early times of SymbolicData we had a dispute about representation of polynomials { use the well established operator syntax as, e.g., x^3+5*x-2, or provide polynomials in XML-based OpenMath or MathML syntax. We decided to store polynomials in the compact human readable operator syntax, as in the PoSSo project.
In the SymbolicData data structure concept we use XML markup mainly to compile heterogeneously structured data into a single resource in such a way that the di erent parts of this data can be extracted by a standard XML parser and passed to appropriate semantic-aware tools for further processing. To start a new data collection within SymbolicData you have to decide about the parts of data that have to be bundled for a single resource, to decide about the syntactical representation of these parts according to the standards of your scienti c subcommunity, to develop a XSchema based XML representation for the bundling, 3 See http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows. and provide data along that standard. The main point about the resources is the reliable and sustainable availability of the data through a permanent web address, a Unique Resource Identi er (URI). We provide access to our centrally managed resources via http://symbolicdata.org/XMLResources/.
Such a concept is not restricted to centrally managed resources, but can easily be extended to other data stores on the web that are operated by di erent CA subcommunities and o er a minimum of Linked Data facilities. There are draft versions of resource descriptions about Fano Polytopes (8630 records) and Birkho Polytopes (5399 records) hosted by Andreas Pa enholz and about Transitive Groups (3605 records) from the Database for Number Fields of Jurgen Kluners and Gunter Malle that point to such external resources. 4
Preparing SymbolicData version 3 we decided to strengthen the part of intercommunity communication aspects. From this point of view resources are owned and maintained by di erent CA subcommunities, and meta data or resource descriptions are important for technically supported interchange of data between such subcommunities and for intercommunity communication, and hence should be managed and maintained within a cooperative intercommunity process.
A rst question to be solved was about data representation for resources and resource descriptions. XML based design principles mainly distinguish between information (XML records) and information structure (described with XSchema) and are well suited for data representation of (basic) resources but proved to be not expressive enough to represent interrelations between di erent resources in a exible way. 4.1
Why RDF?
We decided to switch to RDF as basic representation for resource descriptions by
several reasons. First, we could join forces with the Agile Knowledge Engineering
and Semantic Web (AKSW) Group at Leipzig University4, a leading research
group in semantic technologies, and exploit their experience about concepts and
tools in that area. Second, RDF gets established more and more for exchange of
meta information not only within the Linked Open Data world [
4.2 RDF { the Resource Description Framework { is about description of resources, represented by (globally unique) resource identi ers (URIs). RDF provides a uni ed scheme to represent relational information as triples. There are several notational standards (ntriples, turtle, rdf/xml, json) for triples and plenty of tools to manage sets of triples, i.e., RDF graphs.
Each such triple can be considered as a sentence of a story that consists of a subject s, a predicate p and an object o, but di erent to real stories the semantics of an RDF graph is that of a set, i.e., the order of the sentences does not matter. Hence the expressiveness of RDF stories is very restricted compared to natural languages. The main advantage however, is a separation between data and search algorithms on data patterns as in rule based programming. RDF comes with the standardized pattern based query language SPARQL to operate such search queries on RDF data stores. For SymbolicData we use Virtuoso [20] as RDF data store and SPARQL endpoint.
RDF has another advantage compared to classical database approaches { one can express descriptions of descriptions, i.e., database design, within the same language concepts, and thus share not only descriptions of data but also descriptions of data descriptions, i.e., information about the semantics of the data in a machine readable way.
Subjects and predicates have to be URIs while objects (or `values') can be either URIs or (plain or typed) literals in lexical form (a string included in quotes). There are some prede ned common types (e.g., xsd:integer) but custom types can be de ned as well.
A set of triples can be interpreted as a directed graph (RDF graph) with subjects and objects as nodes (replacing literals by labelled blank nodes) and predicates as labelled edges between nodes. On the opposite, a directed graph can be written as a set of triples (and is commonly represented in such a way as internal data structure of graph programs). Another representation uses sets of key-value pairs p ! o assigned to the di erent subjects s. Note that, di erent to database columns, a key p can have multiple values.
RDF uses some more basic concepts { character sets to compose URIs and
literals and name spaces to structure information spaces and to resolve con icts
within URI creation. There are more elaborated concepts as OWL, RDFS etc.
on top of RDF as explained in the Semantic Web Stack [
The real power of RDF does not originate in an alleged superiority of concepts but in the practical availability of data stores all over the world that are orga
nized on RDF based principles. Whereas the (traditional) Web 2.0 is build upon
interlinked dynamical HTML web pages based on private databases, the
Semantic Web as part of Web 3.0 [
RDF supports both ways of data dissemination { by le transfer as in Web 2.0 and by remote access to RDF triple stores as in Web 3.0 {, and so does SymbolicData: You can download whole RDF graphs as data les from our remote host, upload this data into your local data store and process it locally, but you can also directly access our remote RDF data store. RDF data stores operate on the HTTP protocol and hence are best deployed within a webserver infrastructure, either remote or local. The only di erence between remote and local approaches are the stronger web security requirements for a remote location.
To achieve web access of RDF data on a remote host, URIs should be available
as URLs, i.e., a HTTP Get request to an URI should deliver a valuable portion
of RDF information about that subject. This is the core of the Linked Data
Principle [
RDF resource descriptions are the main part of the meta information collected within the SymbolicData project. We o er resource descriptions for several purposes { resource ngerprints to navigate within the examples, relational information to, e.g., bibliographical references or CA software descriptions, and information about activities of people involved with CA research. 5.1
Semantically equivalent data usually can be given in di erent syntactical form. For example, the same Polynomial System can be given with di erent variable names, in di erent polynomial orderings and even in di erent forms as, e.g., expanded or factorized polynomials.
To navigate within such data, to prestructure data for e cient search or to identify a given example within the database it is helpful to precompile ngerprints, i.e., (semantically sound) invariants of the di erent examples. For example, the set of degree lists (in standard grading) or the set of the lengths of polynomials in distributive normal form are such invariants for Polynomial Systems.
Examples with di erent ngerprints are surely di erent, examples with the same ngerprint require more elaborated methods to be distinguished. In most cases the latter is not worth to be automated since the \general nonsense" knowledge of the experts (optionally added as rdfs:comment to the resource description) is a more powerful \tool" to resolve such disambiguities.
The computation of ngerprints requires semantic-aware tools and both the de nition of useful ngerprints and its computation are due to the CA subcommunity experts with the appropriate semantic knowledge and tools. To compare user given examples with existing ones it is a good advice to have enough invariants as ngerprints at hand that can be computed in polynomial time. 5.2
It was one of the great visions of the SymbolicData Project to collect not only benchmark and testing data but also valuable background information about the records in the database as, e.g., information about papers, people, history, systems etc. concerned with the examples in our collection. It was the main target of SymbolicData version 3 to redesign these data along RDF principles.
We provide a general concept of an RDF class sd:Annotation to store background information in a uni ed way. Instances of this class have predicates { rdfs:label { a label, { rdfs:comment { a text eld for annotation, { sd:relatesTo { a set of related URIs.
We use that concept in particular to relate bibliographical information of type
sd:Reference to di erent data records. The management of bibliographical
references was completely redesigned with SymbolicData version 3 exploiting
RDF and the established Dublin Core ontology [
The same applies to information about and references to CA software that
is SymbolicData-internally stored as resource description of type sd:CAS but
points as far as possible to the relevant information within the swmath database
[
Bibliographical references, references to CA software and even references about contributions to SymbolicData itself refer to people involved with CA research. It is one of the challenges of big data stores about scienti c publications to nd out all publications of a given author, since the same author may be listed in di erent ways in the author list of di erent publications. The big identi cation projects use elaborated evaluation algorithms of cross references to solve this problem or { as the Zentralblatt Mathematik did for a long time { use simple string pattern matching. Some time ago the Zentralblatt started a certain kind of tracking of personal pro les6 to improve that alignment.
We argue that it is a good advise for scienti c communities to support such tracking activities since the bene ts much exceed the drawbacks. Moreover, active involvement of scienti c communities allows to \track the trackers", i.e., to start open discussions and to in uence actively the settings of the tracking process to maximize its bene ts and minimize its drawbacks.
The sd:Person database (274 records) supports that process of disambiguation on the level of references and authors evaluating di erent sources of information about CA publications and relating authorship to sd:Person URIs that are composed following well de ned naming rules. This part of the project is under heavy development with focus on activities within the German Fachgruppe. 6
From the ve stars to be assigned to a Linked Data project according to Tim
Berners-Lee's classi cation [
Much of such interrelation, e.g., a list of interoperability references for people,
software and bibliographical data with Zentralblatt, is on the way. Moreover, we
joined forces with the e orts of the board of the German Fachgruppe to store
and provide information about people and groups working on CA topics at their
new Wordpress driven web site [
The vision of a Computer Algebra Social Network (CASN) goes far beyond that: Get people involved themselves on a regular basis, set up and run within the CA community a semantic-aware Facebook like Social Network and contribute to it about all topics around Computer Algebra using tools that express your contributions in an RDF based vocabulary that the community agreed upon. This sounds quite visionary but is in no way utopic. We operate a rst prototypical node of a tool that realizes the challenging concept of a Distributed Semantic Social Network (DSSN) [19]. 6 See, e.g., the entry https://zbmath.org/authors/?q=ai:grabe.hans-gert of the rst author of this paper. 7 See http://codex.wordpress.org/Shortcode.
We set up a second RDF data store at http://symbolicdata.org/casn/ with information about { upcoming conferences (about 20 entries of type sd:Event), { publications within the \CA Rundbrief" of the German Fachgruppe, { dissertations in CA reported to the board of the German Fachgruppe, { CA projects (initial: projects from the German SPP 1489 priority program) { and CA working groups (initial: as listed by the German Fachgruppe). As the project matures this will be interrelated with the DSSN node at http:// symbolicdata.org/xodx/ running a software under development by the AKSW group in such a way that you can join the CASN and supply your contributions as you can do (also not yet semantically) in any other social network. We refer to our wiki [17] for more information. 17. The SymbolicData project wiki. http://symbolicdata.org/wiki 18. The SymbolicData SPARQL endpoint.
http://symbolicdata.org:8890/sparql 19. Tramp, S. et al.: DSSN: towards a global Distributed Semantic Social Network.
http://aksw.org/Projects/DSSN.html [2014-03-06] 20. Virtuoso Open-Source Edition. http://virtuoso.openlinksw.com/ [2014-02-19]