Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disallow changing prefix of binding ontology #239

Open
egekorkan opened this issue Feb 8, 2023 · 7 comments
Open

Disallow changing prefix of binding ontology #239

egekorkan opened this issue Feb 8, 2023 · 7 comments
Labels
core related to the core specification document refactoring

Comments

@egekorkan
Copy link
Contributor

Call of 08.02:

In order to allow TD parsers that do not have JSON-LD processing capability, it would be good to make sure that a binding is always declared with the same prefix. This would allow the parser to simply check for "htv:methodName" instead of resolving the context.

Everyone in the call seems to be in favor of this, any other opinions?

@JKRhb
Copy link
Member

JKRhb commented Feb 8, 2023

I was wondering if there is some kind of registry for well-known prefixes for JSON-LD. If not, maybe it would make sense to at least define a WoT-specific registry to keep track of all defined prefixes and to avoid conflicts in the future?

@egekorkan
Copy link
Contributor Author

I think it would make sense to at least track the ones we are specifying in our deliverables. Then, I would say that we can track the popular ones separately and avoid using them.

@relu91
Copy link
Member

relu91 commented Feb 9, 2023

I think here is where we see the limitations of thinking that "JSON-LD is just JSON". Forcing a specific prefix limits the flexibility of our TDs as a JSON-LD processor would happily understand another naming, but we can't allow for this flexibility otherwise all other JSON-only parsers will fail.

I'm definitely in favor of this, I also don't know if any of the current implementations are really able to treat a Thing Description as a JSON-LD document. For example, node-wot doesn't (he wouldn't understand myprefix:methodName).

@egekorkan
Copy link
Contributor Author

I have checked with the WoT developers inside Siemens and this direction is also appreciated. The ontologies we specify can have this rule but of course, other ontologies should be allowed and stay flexible.

@egekorkan egekorkan added the core related to the core specification document label Feb 15, 2023
@egekorkan
Copy link
Contributor Author

Call of 22.02:

  • @lu-zero : If we go for a full registry, we can be assertive on this.

@egekorkan
Copy link
Contributor Author

Also see w3c/wot-charter-drafts#57

@egekorkan
Copy link
Contributor Author

Call of 05.04:

  • Should we extend it to all "recommended" ontologies?
  • We have two types of Consumers: Full JSON-LD and basic JSON
  • @lu-zero : we should differentiate between functionality that we cannot constrain and should constrain for interoperability (interacting with the Thing). (schema.org prefix can change but not protocol binding vocabularies). This seems to be the group opinion.
  • @ashimura : we should talk with JSON-LD experts to align with their approach. If we add an assertion, it should be a "SHOULD" assertion.
  • We should make sure that TDs do not omit @context objects with e.g. cov.
  • @lu-zero : Processing the TD via fetching all the ontologies would be too much processing.
  • We need to provide explanation on how to handle prefixes and JSON-LD processing.
  • @mjkoster : plain JSON consumers use the contentType registered at IANA.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core related to the core specification document refactoring
Projects
None yet
Development

No branches or pull requests

3 participants