Conversation
|
|
||
| <triples_rdf_1_1/pos_001> a jellyt:TestPositive, jellyt:TestRdfFromJelly ; | ||
| mf:name "A set of three triples with only IRIs as terms" ; | ||
| rdfs:comment "A set of three triples with only IRIs as terms. Stream options are: generalized-statements=false, rdf-star=false, max-name-table-size=8, max-prefix-table-size=0, max-datatype-table-size=0." ; |
There was a problem hiding this comment.
do we put all stream options in the comments or leave it all to stream_options.jelly? Initially, it was done mostly for me so that I would not forget what I used, but it does not make much sense to duplicate this info as it is taken from the stream options file
There was a problem hiding this comment.
You can choose whatever way makes most sense to you. I just copy-pasted what you wrote. Feel free to change this later.
Co-authored-by: Anastasiya Danilenka <41057639+adanilenka@users.noreply.github.com>
Co-authored-by: Anastasiya Danilenka <41057639+adanilenka@users.noreply.github.com>
|
|
||
| # Instances -- requirements | ||
|
|
||
| jellyt:requirementPhysicalTypeTriples a mf:Requirement ; |
There was a problem hiding this comment.
I like the requirements, but why are they not in the current examples?
There was a problem hiding this comment.
Because I forgot to commit them, that's why :D sorry. Good catch!
Is it OK now?
|
@Ostrzyciel I was thinking about a property that will accompany mf:Requirement and help distinguish between core vs supported specification functionality, e.g., generalized RDF and RDF-star are supported but not required. So marking them will help skip them, what do you think? |
That ties into the thing mentioned here: #24 I'd say that even supporting the TRIPLES type is optional. Everything mentioned under requirements is. If you want to write a producer that only supports writing quads because that's your use case -- fine. These requirement annotations will allow implementations to skip the parts that they chose to not implement. Then we can mark those cases as "unsupported" instead of "failed" in test case reports. Makes sense? |
|
yes, sounds good, thank you for this clarification |
Issue: #25
This adds a simple vocabulary for test cases, with two example manifests.
There is no validation or compilation to docs yet.