The main task for this week is still updating the YesWorkflow Model Vocabulary and Structure, and modifying SPARQL queries for advanced questions. This is our GitHub repository including the Model Specification, RDF Turtle facts, and SPARQL queries: simulate_data_collection example
For the SPARQL queries, the combined queries which are based on both RDF model facts and recon facts are sophisticated. There are many connections between model and recon facts, and many possible ways should also be considered by virtue of FILTER / FILTER NOT EXISTS / UNION clause query statements. Besides, the common ancestors and lowest common ancestor (LCA) questions in Datalog language are complex when implementing in SPARQL query engine. I did a lot of research on dealing with recursive queries and complicated filter queries in SPARQL. I feel that one of the apparent features of SPARQL language is the repeat-ability of subjects and objects in the statements even if different names are used for them.
For the YesWorkflow Model vocabulary, we thought about differentiating the “connectsTo” relationship between Port and Data. In other words, we intended to use “yw:reads” association between InPort and Data, and to use “yw:writes” between OutPort and Data, which could make it more reasonable for semantic understanding. While, we are still under discussion about thinking of a way to connect retrospective Resource to prospective classes. The URIVariable of Resource and the Data actually share the same name, but currently they are in retrospective and prospective world respectively.
For the following weeks, I suppose to think about a proper deliverable product for our summer intern work.