CLI loads local file

[shnydercom]

Fixes #145

the --ontology argument will have priority, unless it explicitly isn't prefixed with "https://", then there's an additional --file argument now. So you have to deliberatly switch it off, like so: schema-dts-gen --ontology=doNotUse --file=./somefolder/ontology.nt

[shnydercom]

I ran into an issue with the compilation result, when it has schema.org in the context, but computes my local ontology. Then "Thing" is still the topmost type, but isn't defined. I would want to have the schema-ontology in one file and my own in another, and add a (typescript) import statement. Would be fine to do that manually. What's your take on this?

Here's how it looks in VS Code:

and here's my ontology:

<http://ldui.net/ontology/Button> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2000/01/rdf-schema#Class> .
<http://ldui.net/ontology/Button> <http://www.w3.org/2000/01/rdf-schema#comment> "A Button, if it's a physical, or virtual pressable device of simple intention" .
<http://ldui.net/ontology/Button> <http://www.w3.org/2000/01/rdf-schema#isDefinedBy> <http://ldui.net/ontology> .
<http://ldui.net/ontology/Button> <http://www.w3.org/2000/01/rdf-schema#label> "Button" .
<http://ldui.net/ontology/Button> <http://www.w3.org/2000/01/rdf-schema#subClassOf> <http://ldui.net/ontology/UIElement> .
<http://ldui.net/ontology/Element> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2000/01/rdf-schema#Class> .
<http://ldui.net/ontology/Element> <http://www.w3.org/2000/01/rdf-schema#isDefinedBy> <http://ldui.net/ontology> .
<http://ldui.net/ontology/Element> <http://www.w3.org/2000/01/rdf-schema#label> "The base for all Classes in the ldui ontology, both as part of the UI or not" .
<http://ldui.net/ontology/Element> <http://www.w3.org/2000/01/rdf-schema#subClassOf> <http://www.w3.org/2000/01/rdf-schema#Class> .
<http://ldui.net/ontology/UIElement> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2000/01/rdf-schema#Class> .
<http://ldui.net/ontology/UIElement> <http://www.w3.org/2000/01/rdf-schema#comment> "The base class for all User Interface elements" .
<http://ldui.net/ontology/UIElement> <http://www.w3.org/2000/01/rdf-schema#isDefinedBy> <http://ldui.net/ontology> .
<http://ldui.net/ontology/UIElement> <http://www.w3.org/2000/01/rdf-schema#subClassOf> <http://ldui.net/ontology/Element> .
<http://ldui.net/ontology/UIElement> <http://www.w3.org/2000/01/rdf-schema#subClassOf> <http://www.w3.org/2000/01/rdf-schema#Class> .
<http://ldui.net/ontology/UserInteraction> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2000/01/rdf-schema#Class> .
<http://ldui.net/ontology/UserInteraction> <http://www.w3.org/2000/01/rdf-schema#comment> "The base class for all minor interactions users have with the interface (click, scroll, etc.)" .
<http://ldui.net/ontology/UserInteraction> <http://www.w3.org/2000/01/rdf-schema#isDefinedBy> <http://ldui.net/ontology> .
<http://ldui.net/ontology/UserInteraction> <http://www.w3.org/2000/01/rdf-schema#subClassOf> <http://ldui.net/ontology/Element> .
<http://ldui.net/ontology/UserInteraction> <http://www.w3.org/2000/01/rdf-schema#subClassOf> <http://www.w3.org/2000/01/rdf-schema#Class> .
<http://ldui.net/ontology/triggersAction> <http://schema.org/domainIncludes> <http://ldui.net/ontology/Button> .
<http://ldui.net/ontology/triggersAction> <http://schema.org/rangeIncludes> <http://ldui.net/ontology/UserInteraction> .
<http://ldui.net/ontology/triggersAction> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/1999/02/22-rdf-syntax-ns#Property> .
<http://ldui.net/ontology/triggersAction> <http://www.w3.org/2000/01/rdf-schema#comment> "The (UserInter)-Action that gets triggered by a Button" .
<http://ldui.net/ontology/triggersAction> <http://www.w3.org/2000/01/rdf-schema#isDefinedBy> <http://ldui.net/ontology> .
<http://ldui.net/ontology/triggersAction> <http://www.w3.org/2000/01/rdf-schema#label> "triggersAction" .

[Eyas]

Hmm. This is challenging because you still need a "top" type (e.g. for WithContext). If you import Thing from schema-dts, it wouldn't include your types and you wouldn't be able to put them in a Graph or sub-type.

Right now schema-dts-gen always expect a Thing top-type to be defined.

A few solutions:

1. Include your own very basic definition of <https://schema.org/Thing> as an empty class

2. Change the CLI to be able to support mutliple ontologies and just combine them, for example, instead of `--ontology or --file, maybe have --ontology accept a comma separated string, such that you can pass:

   --ontology=https://schema.org/blah/foo.nt,file:///full/path/to/my.nt,./maybe-even/a-relative/path.nt

[shnydercom]

please have a look at it - I haven't got much experience with testing file system access in node.

Also a minor issue: Running the lint-fix modifies all the files, including json-files. In the comparison view I don't see any difference, is there a OS-specific file or line ending? I tried it both on windows and on WSL2

[Eyas]

I've seen this before too. Running git add on all the changed files suffices: they stop showing up in the commit, but the linter stops complaining.

Not sure why it's happening.

[Eyas]

Looks good! What did you decide to do with the fact that .nt files might not include references to Thing or top types? Your local fill will just be a merged version of both?

[shnydercom]

Looks good! What did you decide to do with the fact that .nt files might not include references to Thing or top types? Your local fill will just be a merged version of both?

My opinion after some experimenting is that this library is named "schema-dts" so that problem is out of the scope of this library. For now I put

<http://schema.org/Thing> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2000/01/rdf-schema#Class> .
<http://schema.org/Thing> <http://www.w3.org/2000/01/rdf-schema#comment> "The most generic type of item. Duplicate of schema:Thing-ontology, deprecate as soon as possible" .
<http://schema.org/Thing> <http://www.w3.org/2000/01/rdf-schema#isDefinedBy> <http://ldui.net/ontology> .
<http://schema.org/Thing> <http://www.w3.org/2000/01/rdf-schema#label> "Thing" .

into my ontology to get a "local" build.

Another example for scope: SDO has a particular way of describing type-relationships, uses domainIncludes and rangeIncludes for example. I found https://www.w3.org/TR/owl-ref/#cardinality-def and it would help with my ontology for UIs (e.g: one button can only have one label). Generating typescript for that isn't something I'd expect here though.

The thing is that schema.org is (afaik) blocked in mainland China, so an online approach to linked data build pipelines would stop working there. For that case I believe it makes sense to let people build from local files.

[Eyas]

Sounds good.

FWIW, within reason, I'm happy to support some widely used predicates that declare ontologies. I've had a longstanding hope to support OA for example. But Schema.org support will always be a higher priority.

[shnydercom]

OA looks really interesting and potentially useful! Thanks for sharing the link. Do you have a usage example? For a lot of the linked data projects I find it difficult to find them used "in the wild", but they're more thought-through than the average REST or GraphQL API.

[Eyas]

I was sure I had an issue showing an example usage in the wild, but I can't seem to find it.

Point taken re: finding usages "in the wild", but unless you have a better idea (Im all ears!), it seems like a necessary evil to prevent a tool from becoming ad hoc.

[shnydercom]

In my experience it looks like the low entry barrier of an ad hoc-tool drives usage, people want something they can play with. Otherwise there's a lot of concern that the constraints are limiting instead of guarding. So now I first look at existing devX and UX and then at how much I like a concept.

Did that the other way around before: I was kind of set on hydra to become the next de-facto standard for APIs, and then graphql did. Graphql allows pretty messy implementations, and companies often favor implementation speed over architecture. The speed that graphiql and the code-generators brought, although not fully compliant at first, brought in more devs and their problems. And now relay solves problems that graphql didn't address before. So I guess my point would be to address user/dev problems first and once they start overlapping solve that with a standardized solution.

The value proposition of schema.org is still pretty abstract, that's why I like this library: It improves ease of use a lot. I'm trying to get an idea of how popular the topic is with implementers, so I've written a post about it. So far either my writing or the topic didn't get much attention ;)

[Eyas]

Nice post! -- and yes, attention on dev.to is pretty hit or miss.

Point taken, and there's definitely a trade-off to be made somewhere on this spectrum.

The value proposition of schema.org is still pretty abstract

This is a fair statement to make about linked data and the Semantic Web in general, as concepts. But take a look at how people suggest new schemas for Schema.org for a time and a few patterns will emerge:

• There are obvious specialized value propositions, e.g. (a) there was a big push for better structured data in the life sciences some time ago, and (b) there's been a recent push to have better public data/statistics [e.g. datacommons.org] that have resulted in improvements to QuantitativeValue and StatisticalPopulation, etc.
• There are generalized value propositions around SEO specifically, but more generally enabling crawlers to create better knowledge graphs (think wikidata, and the internal equivalents at Google and elsewhere)

Using schema.org purely as an API language might get you more headaches than benefits in the general case, unless the data your representing benefits from being seen a set of entities in a semantic graph. But your mileage may vary.

[Eyas]

Forry for the delay, but this is finally included in v0.8.3