Page Comparison

...

1. How will we implement tags?
   
   • Option 1:As plain text that is appended to slide revisions and decks (e.g. tags: [mathematics, fibonacci, ...] or
     
     • Pros: easy to implement
     • Cons: 
   • Option 2: as URIs that are already linked to further knowledge (RDF)?
     • Pros: we might be able to infer knowledge from the WWW, we might be able to present a user enriched recommendations
     • Cons: we might not be able to link to distinct topics/concepts in case we are unsure about the meaning of a tag
   • Option 3: as both URIs and Tags (Mariano Rico ) providing both options as Plain text and url like this: '{ name: Scientific, url: http://dbpedia.org/ontology/Scientific }'. (Aleksandr Korovin ) (Option 3 added by Klaas Andries de Graaf for discussion overview purposes - check if I misunderstood argument/pro's/con's)
     
     • Pros: Can get language label via DBpedia via URI (Mariano Rico , see SWIK-903). User can still specify tag without URL (Aleksandr Korovin)
     • Cons: not good for keyword searching in MongoDB - Typical model data is an array (https://docs.mongodb.com/manual/tutorial/model-data-for-keyword-search/). Need to test query that will search in tags array by name:  tags: \[{name: 'name1', ...}, \{name: 'name2'} , .... ] (Aleksandr Korovin) → also in SOLR? (Serafeim Chatzopoulos )
       
     • Possible complication: disambiguation problem tag → URI link.
   • Other options? (Ali Khalili , Roy Meissner  , Mariano Rico , Antje Schlaf , Luis Daniel Fernandes Rotger )
2. How do we save these tags?
   
   • Option 1 - As part of the slide model in the MongoDB or
     
     • Pros: easy to add to our current model, same technology stack
     • Cons: possibly complex (+long running) queries to find things that are related to tags, more complex to add information from the WWW. for reasoning, inferring knowledge, semantic search we will need a RDF store with SPARQL endpoint working in a real time for users, right (T2.4) (Aleksandr Korovin , Klaas Andries de Graaf agrees)
   • Option 1.1 - JSON-LD (Allan Third) (option 1.1. added by Klaas Andries de Graaf for discussion overview purposes - check if I misunderstood argument/pro's/con's)
     
     • Pros: there's no separation between the Mongo representation and the RDF. can help for SEO if embedded in pages (Ali Khalili ) . Graph-db supports JSON-LD (Aleksandr Korovin)
       
     • Cons: shouldn't be such a disruptive change, it should just involve adding some fields to the JSON that's there (Allan Third) add \@context field with context.json and that is all (Aleksandr Korovin ).May need additional mapper to triple-DB for fast SPARQL queries (see additions/complications below)
       
     • Additions/complications: needs SPARQL mapper for querying (Aleksandr Korovin). the on-the-fly conversion of a SPARQL request to a mongodb request can be too slow for complex SPARQL queries. I vote for a off-line RDF generation by means of mappers. (Mariano Rico) for performance reasons I also am more apt to using a triple store rather than on-the-fly query rewriting. go for both approaches, do a benchmarking and then decide (Ali Khalili) .
   • Option 2 - as a separate DB (e.g. a Graph DB - read next section)
     • Pros: simple queries, leverage default Semantic Web technologies (like interlink/infer knowledge on the WWW), no schema boundries
     • Cons: possibly not so good performance, another technology stack. Needs synchronising. How to search both GraphDB and MongoDB?
   • Other options? (Ali Khalili , Roy Meissner , Mariano Rico , Antje Schlaf , Luis Daniel Fernandes Rotger )
   • Related:
     
     • RML - http://rml.io/
     • Karma - https://usc-isi-i2.github.io/karma/
     • SparqlMap - https://github.com/tomatophantastico/sparqlmap/
     • morph-xr2rml - https://github.com/frmichel/morph-xr2rml
       
       
3. How do we realize semi-automatic semantic annotation of decks and slides?

...