Mudchar ontology

[calummackervoy]

Requires Multi-User-Domain/vocab#3 and Multi-User-Domain/mud-react#16

• Added custom MissingRequiredArgumentException and handler meaning that this will raise a 400 to client
• Removed SettlementController (replaced by generic DataController)
• Basic inferencing in the AbstractTaskActor, so that for example I can pass POST Transit any subclass of mud:Locatable and it will work

[calummackervoy]

If you test this branch locally it won't work because this ontology is in the character branch until we merge it (but merging it will break the master branch of Jena/React until this PR is merged)

This is a bit of a pain (namely using branch/WIP ontologies)... do you know of any deployment magic that we can use @MattTennison ? 😄

[MattTennison]

Hmm. Would it be bad practice in semantic web to regularly update these URLs?

Because we could link to specific commits instead of the master branch, and as long as we do a proper merge (i.e. not squash) it'll end up in the master branch.

Alternatively we could look into a way of serving these vocab files locally, and configure the endpoint via an environment file? So locally you could have http://localhost:<vocab-port>/mudchar.ttl, whereas in real deployments/as the default you'd fallback to this GitHub URL

[calummackervoy]

Would it be bad practice in semantic web to regularly update these URLs?

yeah they should never change actually 😅 note Multi-User-Domain/vocab#1

Alternatively we could look into a way of serving these vocab files locally, and configure the endpoint via an environment file?

I'm not sure I get it - would it cause issues with the vocabularies which are linked to "permanent" vocabs ? Like the one I link to solid-terms ?

[MattTennison]

yeah they should never change actually sweat_smile note Multi-User-Domain/vocab#1

Ah, only the very first issue 😅 Okay, let's not do that

I'm not sure I get it - would it cause issues with the vocabularies which are linked to "permanent" vocabs ? Like the one I link to solid-terms ?

Not sure, but I can elaborate on the idea:

1. Use a environment variable for the vocab hosting endpoint here in mud-jena. For now, as we're using these GitHub branches, it could default to https://raw.githubusercontent.com/Multi-User-Domain/vocab/main
2. Run a static asset server (e.g. https://hub.docker.com/r/halverneus/static-file-server, or could write our own) to serve these .ttl files in development. Let's say we run it on port 7000 locally.
3. Change the environment variable for development to be http://localhost:7000, so responses reference ontologies from http://localhost:7000/mudchar.ttl instead of GitHub.

So locally yeah, your responses are fairly useless from a semantic web pov - they'd reference ontologies that only you can access. But once it's merged and deployed somewhere proper, it would "just work", referencing GitHub assets. I suppose though it'd cause trouble if you were going between say, one real mud-jena server and your local one. Is that something we ought to account for upfront?

[calummackervoy]

Ah yeah this is a nice idea :) I copied it into an issue here: Multi-User-Domain/vocab#4

I like the way that it solves our problem but that a user only needs to do it if they want to change some vocab, and even then only needs to do it locally

I guess that it will only affect the vocabularies which we choose it to, if we explicitly fetch the environment variable

I got to thinking about how we re-define the same vocabulary LITs when we use them in Jena and React and opened this Multi-User-Domain/vocab#5

[calummackervoy]

I suppose though it'd cause trouble if you were going between say, one real mud-jena server and your local one. Is that something we ought to account for upfront?

Hmm tricky one 😅