What's the expected form for the @domain value?

[Peeja]

It looks like a m-ld @domain is always specified as a DNS-style name in the examples, but I couldn't find anything in the spec that explicitly said that that's a requirement. Is it allowed to be any string, or is it specifically meant to have a DNS-style form? The more I think about what it represents, the more I'd like to use an IRI there, as the domain feels to me akin to a graph and a resource. I think it would make sense to:

• Have triples (in the domain or elsewhere) where the subject or object is the domain itself,
• Use the domain as the fourth term when looking at the triples in the domain as quads, and/or
• Make the domain IRI dereferenceable to get the data in the domain—by hosting a data dump there, or by using that location as a basis for cloning the domain, or by hosting a SPARQL endpoint there, or any combination of these and other means of access through content negotiation.

I certainly wouldn't expect any of these to be requirements to use m-ld, but I think it could be valuable to have the option. If any string is allowed for the @domain, then we essentially already have that option, I just don't see it guaranteed in the spec currently, and I don't want to violate an unwritten assumption and have stuff break down the road. 😃

[gsvarovsky]

Hey @Peeja thanks for your interesting thoughts. I totally agree!

Is it allowed to be any string, or is it specifically meant to have a DNS-style form?

It's meant to be DNS-style, and it's checked by the Javascript engine. So for now, you can't use any IRI. However, this was really just intended to have a very easily explained algorithm for the default JSON-LD context @base and @vocab.

Right now, you can set your own context in the clone configuration, and provide your own base and vocab.

See https://js.m-ld.org/interfaces/meldconfig.html#_context

But I really like your ideas for using the domain as a resource, makes perfect sense. In fact I've identified a need for it myself, in the security project. I'm writing up my ideas right now but you can see a sneak preview here: https://github.com/m-ld/m-ld-security-spec/blob/main/design/img/agreement.class.svg 😎

Let's make a ticket in this repo...

[uvdsl]

@gsvarovsky , what exactly is the difference between @domain from m-ld and @vocab from json-ld?
For me, it seemed quite intuitive that they would be the same, i.e. "look at the IRI of @domain to discover the vocabulary of that domain. I thought that @domain was just a renaming in order to not get confused between json-ld and m-ld internals...?

Now thinking about it, one could of course argue that @domain should not identify the same thing as @vocab. Because you could provide more information on your domain (whatever this means), while using the specified vocab for modelling.
But then, @vocab should be a mandatory field for initialisation, I think...?

Soooo, question is:
Is @domain supposed to denote modeling information like @vocab (identifying an ontology/model)
or
is @domain identifying a specific object or meta-data from the domain, which itself may be modeled by @vocab (identifiyng a specific object/"implementation of a model")?

Edit: Oh and I am all for IRI-style @domain, of course :)

[gsvarovsky]

Hi Christoph, thanks for the question. The @domain and @vocab are quite different things, which have a default relationship. Let me try to clarify:

• The @domain is a unique identity for the dataset (or 'document' or 'graph') that is being shared. It is most practically used for telling the 'remotes' (the networking layer) which other clones to connect to (for example, via a pubsub 'channel'). https://js.m-ld.org/interfaces/meldconfig.html#_domain
• The @vocab provides a base IRI for unqualified properties in reads and writes, has a default value of http://<@domain>/#, but only if it has not been specified in the configured @context. https://js.m-ld.org/interfaces/meldconfig.html#_context

The intention is that using a JSON-LD Context in the configuration is an 'advanced' feature, which is not really important if you're doing a closed-world app. The vocabulary default ensures that if you did compare triples across different domains, there would be no ambiguity about which domain they belong to. Using a Context, however, allows you to be very clear if two domains share a vocabulary.

So if you are building a linked-data app, it would often make a lot of sense to specify the @vocab in the Context. Note that it's also possible to specify a @context field in any read or write json-rql pattern or JSON-LD document; or, of course, you can use fully-qualified IRIs in the data.

In a small way, the idea to allow a full IRI for the domain makes this a little more confusing, because now both things are IRIs. However the advantages are clear and strong, as you agree.