Removed domain, object vs data property, rdfs:label, Array[]-> Vehicle

[mspaulik]

Hello @bterlson, I have implemented the following:

• Remove domain from data properties.
• Distinguish between DataProperty and ObjectProperty.
• Added "rdfs:label" .
• Changed Array[] to Vehicle in Owner Object property.
• Ordering of the file so that classes are in the beginning and properties afterwards. 3rd section will be SHACL constraints.
• SHACL part.

[mspaulik]

Hello @bterlson , I have addressed all your comments.

Just to explain, since I really need writer.blank() function to be present (and its not present in Store() which I tried to use in the first place, only addBlankNode() function exists which doesn't produce same effect), I couldn't really create 3 arrays as you suggested and simply add quads to them. So what I did instead was creating 3 different writers and iterating through all 3 of them at the very end.

However, I am getting an issue with namespacing - namespaces are written to ttl 3 times and example namespace is not picked up? I am a bit confused by the function 'getNsForModel' and didn't know how to modify it to make it work. Would you mind altering the code in this function so that it works with '3 writers' logic I am currently doing? I couldn't come with better solution due to blank() function needed.

Thanks!

[mspaulik]

Hello @bterlson,

I am having some issues when processing this model: model CUSIP is string;

Basically, I am trying to generate these RDF lines: ex:CUSIP a owl:DataProperty; rdfs:label "CUSIP"; rdfs:range xsd:string.

If following the same logic as we did for others models (model Person or similar standard models) it doesn't work (note: I am now doing if/else in the beginning to check what kind of model we are processing). Basically, the function getIntrinsicModelName should return CUSIP, however, it returns string? Could you have a look? Is there an issue on CADL side with this?

I was trying to get around the issue by calling m.name (which returns CUSIP). However, if we do nn(m.name) instead of getting ex:CUSIP , I am getting \<CUSIP> generated in my ttl file.

I have pushed my code so you can have a look (its marked with TODO).

Thank you!

[bterlson]

If following the same logic as we did for others models (model Person or similar standard models) it doesn't work (note: I am now doing if/else in the beginning to check what kind of model we are processing). Basically, the function getIntrinsicModelName should return CUSIP, however, it returns string? Could you have a look? Is there an issue on CADL side with this?

This behavior is by design (though confusing I admit, we are looking at cleaning it up, viz: https://github.com/microsoft/cadl/issues/1187). getIntrinsicModelName is telling you the type of CUSIP isn't an object but a string. You should just use the model name as the name which you tried, will look into why the output looks wonky.

[bterlson]

The angle bracket syntax occurs when referencing a node by URI. Because CUSIP doesn't have a prefix, the writer assumes it's a URI and wraps it in angle brackets. I think the right fix is to make nameForModel return the actual name of the model. I've committed a change that does this.

(Also note that my editor insists on formatting, if you have editor plugins available consider installing prettier and autoformatting on save)

[bterlson]

I've added some commits which I think address all the above feedback/issues.

The multiple namespaces in the ttl is caused by using three writers - because the writers don't know about eachother, each one writes the namespaces out. In general using three writers is likely going to be swimming upstream as concatenating three separate .ttl files together doesn't seem necessarily safe?

I investigated just doing the "store quads in an array" approach and I think I got it working? It seems to work fine to use writer.blank and writer.list with the quad() factory (despite a type error in the latter case), so this approach goes that route rather than use the separate writers. If I missed a reason why this approach doesn't work though let me know!

[mspaulik]

Thank you very much for your input! I believe we can merge it now? :)

[mspaulik]

I have also implemented some of the in-built decorators (for models and for model props). Will need to figure out how to do implementation for custom ones next week too. Please review if all makes sense :)

[mspaulik]

Hello @bterlson , fixed both. Thanks!

[bterlson]

Looks good, nice work!