-
-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Working on paper #406
base: main
Are you sure you want to change the base?
Working on paper #406
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,28 @@ | ||
> Here we will put the text for the paper. Later, it will be slightly reformated to meet JOSS's submission criteria. For now, it's mostly copy-paste-edit from the manual or readme. | ||
|
||
|
||
## Schema Salad: A bridge between document and record oriented data modeling and the Semantic Web | ||
|
||
### Summary | ||
Salad is a schema language for describing structured linked data documents in JSON or YAML documents. A Salad schema provides rules for preprocessing, structural validation, and link checking for documents described by a Salad schema. Salad builds on JSON-LD and the Apache Avro data serialization system and extends Avro with features for rich data modeling such as inheritance, template specialization, object identifiers, and object references. Salad was developed to provide a bridge between the record oriented data modeling supported by Apache Avro and the Semantic Web. | ||
|
||
### Statement of need | ||
The JSON data model is a popular way to represent structured data. It is attractive because of its relative simplicity and is a natural fit with the standard types of many programming languages. However, this simplicity comes at the cost that basic JSON lacks expressive features useful for working with complex data structures and document formats, such as schemas, object references, and namespaces. | ||
|
||
JSON-LD is a W3C standard providing a way to describe how to interpret a JSON document as Linked Data by means of a "context". JSON-LD provides a powerful solution for representing object references and namespaces in JSON based on standard web URIs but is not itself a schema language. Without a schema providing a well-defined structure, it is difficult to process an arbitrary JSON-LD document as idiomatic JSON because there are many ways to express the same data that are logically equivalent but structurally distinct. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It seems like we should add some final sentence at the end giving the idea "And that's why we developed schema-salad". Otherwise, the thoughts go from JSON to JSON-LD and its limitations and then break off. |
||
|
||
### State of the field | ||
>It's better to extend or rework this section as _references should include full names of venues, e.g., journals and conferences, not abbreviations only understood in the context of a specific discipline_ | ||
|
||
Several schema languages exist for describing and validating JSON data, such as JSON Schema and Apache Avro data serialization system, however, none understand linked data. As a result, to fully take advantage of JSON-LD to build the next generation of linked data applications, one must maintain separate JSON schema, JSON-LD context, RDF schema, and human documentation, despite the significant overlap of content and obvious need for these documents to stay synchronized. | ||
|
||
Schema Salad is designed to address this gap. It provides a schema language and processing rules for describing structured JSON content permitting URI resolution and strict document validation. The schema language supports linked data through annotations that describe the linked data interpretation of the content, enables generation of JSON-LD context and RDF schema, and production of RDF triples by applying the JSON-LD context. The schema language also provides for robust support of inline documentation. | ||
|
||
### Mentions | ||
> Put here recently submitter CWL paper. The title of this section should be changed into something meaningful. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
|
||
### Examples | ||
> I think it's would be great to put here some of the schema-salad examples (if we are still within 1000 words limit) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @pjotrp can you say a few works about the use of schema-salad in PubSeq? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes. Let me have a look. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the reader would be best served with a few examples. Show a JSON record and a mapping and the RDF or JSON-LD output. I mean the strength of schema salad is a simple translation with error checking. To be honest, I only understood what schema salad was about when I ran something. That is how you can help the interested user. Does that make sense? We can use examples from PubSeq for sure. Does that make sense? If you inject the images as figures they don't count as words. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It would be nice to have PubSeq examples in this paper. We can also mention PubSeq in the Mentions section (this section will be renamed later, but it's for a representative set of past or ongoing research projects using the software and recent scholarly publications enabled by it). As for the figures, I don't think they count them as words. Here is an example of how they add figures into the papers FiguresFigures can be included like this: Figure sizes can be customized by adding an optional second parameter: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am proposing to turn examples (YAML/JSON/RDF) into figures, so they don't count as words. |
||
### Acknowledgements | ||
### References | ||
> References are built automatically from the content in the `.bib` file. So this section should be empty. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some thoughts to not forget about.
Assuming I'm a person who read it for the first time. When I see the sentence
I have questions "What exactly is that bridge and why do I need it? Where do I use record-oriented data and how that bridge will make my life easier?" We need to make sure we answer these questions somewhere in the paper.
Also, based on this, Record-Based Data Model has three subtypes.
When in the paper we say record-oriented data modeling, do we mean all three subtypes or only Hierarchical Data Model?
Why do people like the Hierarchical Data Model - simplicity, data integrity, easy availability of expertise. Why do people don't like the Hierarchical Data Model - lack of standards (and here we are with Schema Salad), lack of querying facility, inflexibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my opinion the README is not great. It does not explain in layman's terms why we have schema salad and why we need it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can argue the README is for experts. But I think the JOSS paper is an opportunity to explain things well.