Suggestion about `@prefix`

[hsolbrig]

How difficult would it be able to set @prefix globally? We've got quite a collection of non-standard prefixes and it kind of busies up the context document when we have to add the properties individually?

{   "@context": {
        "@prefix": true,
        "CHEBI": "http://example.org/CHEBI_",
        "CUBBY: "http://example.orrg/CUBBY_"
   }
}

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

Rob Sanderson: https://github.com/w3c/json-ld-syntax/issues/329
Harold Solbrig: I have a number of prefixes ending with underscore,
… rather than hash or slash (so not considered as prefix by default);
… it would be nice to be able to set @prefix=true globally,
… instead of specifying per term.
Rob Sanderson: would that apply to all terms in the context?
Gregg Kellogg: this would apply to all terms except those explicitly marked with @prefix=false
… and this would be meant to be used in subcontexts.
Harold Solbrig: the ramifications are big…
Gregg Kellogg: this is actually what 1.0 was doing initially;
… there was an errata to prevent just any IRI to be used as a prefix
Gregg Kellogg: See errata mail
Gregg Kellogg: See JSON-LD 1.0 errata
Harold Solbrig: let me time to ponder on it a little more
Rob Sanderson: gkellogg any more issues we should discuss?

[hsolbrig]

Just to double check - in JSON-LD 1.0, there is no way to make the following work:

{   "@context": {
          "CHEBI": "http://example.org/CHEBI_"
     },
    "CHEBI:item1": true
}

See: http://tinyurl.com/tn8k2fd

While I'm thinking of it, is it expected behavior that the above emits a triple while

http://tinyurl.com/w5qdz4c

Does not?

[hsolbrig]

In general, can someone verify that ALL of the behaviors below conform to the spec?

http://tinyurl.com/wwl2yk2

[gkellogg]

Just to double check - in JSON-LD 1.0, there is no way to make the following work:

{   "@context": {
          "CHEBI": "http://example.org/CHEBI_"
     },
    "CHEBI:item1": true
}

Yes, in the updated JSON-LD 1.0 (after errata), CHEBI won't be usable as a prefix, so it is treated as an IRI scheme.

See: http://tinyurl.com/tn8k2fd

While I'm thinking of it, is it expected behavior that the above emits a triple while

http://tinyurl.com/w5qdz4c

Does not?

This does not emit a triple (or expand), as "item1" is not a defined property. If you used @vocab as a catch-all to define it, it would create a triple.

[gkellogg]

In general, can someone verify that ALL of the behaviors below conform to the spec?

http://tinyurl.com/wwl2yk2

Those seem correct. P1-6 all are defined using IRIs and the x:item? properties all have the form of an IRI (with scheme x).

[hsolbrig]

We definitely need this fix. The problem we face is that the prefixcommons library uses JSON-LD contexts both as raw JSON maps and in rdflib json-ld parsers. See: https://github.com/biolink/biolinkml/blob/master/notebooks/context_issue.ipynb for a description of the details.

The prefixcommons library, which has widespread use in the bioinformatics community, has a significant number of prefixes that do not end in '/' or '#'. Based on the above responses, our options using JSON-LD 1.0 are quite limited, and we will probably end up patching rdflib-jsonld to reverse https://lists.w3.org/Archives/Public/public-rdf-comments/2018Jan/0002.html with our fingers crossed that issue it fixes doesn't appear in any of our target JSON.

In the longer (JSON-LD 1.1) term, we would like to be able to import the existing contexts, adding a global "@prefix": true, as the per-prefix fix simply won't work.

[niklasl]

@hsolbrig would the form suggested in https://github.com/w3c/json-ld-api/issues/76#issuecomment-582650517 work for you? That is, this:

{
  "@context": {
    "@prefix": {
        "dc": "http://purl.org/dc/terms/",
        "tag": "tag:example.org,2020:ns:",
        "compact-iris": "http://example.com/compact-iris-"
    }
  },
}

It'd require a slight change in usage, but that form is usable as a simple raw JSON dictionary.

[hsolbrig]

I've put a query out to the prefixcommons community -- hoping to hear back soon. I like where it is going but it does have some interesting ramifications.

[cmungall]

Hello all, I represent the Open Bio Ontologies (OBO) Foundry (http://obofoundry.org) which is the leading collection of ontologies in biomedicine and the life sciences.

All OBOs use PURLs of the form http://purl.obolibrary.org/obo/$NAMESPACE_$LOCALID, for which we have canonical CURIEs of the form $NAMESPACE:$LOCALID. A lot of our stack has been using JSON-LD contexts (which we love) with mappings of the form

 "NAMESPACE":  http://purl.obolibrary.org/obo//NAMESPACE_"

This has been largely working but I guess this is not following the standard and it is not robust to rely on this behavior?

I would be very much in favor of technical solutions that don't bake in assumptions about the syntactic structure of URIs, which should be opaque to software.

[wdduncan]

The NAMESPACE_ prefix works fine in the JSON-LD 1.0 playground. What changed?

[hsolbrig]

While I'd like to discuss the above approach as it would make some of the contexts we are generating more readable, the ideal solution for the prefixcommons community would be to have an API flag that says "treat everything as a prefix". That would allow code that reads contexts as JSON to work unchanged and would require minimal changes to the API calls once the 1.1 software is in place

[wdduncan]

Interestingly, in LD 1.1, using the "@id" designator does not always work as expected when using "#".
For example:

{
  "@context":
  {
    "foo": "http://ex.com/foo#",
    "bar": {
      "@id": "http://ex.com/bar#"
    }
  },
  "foo:123": "baz",
  "bar:456": "blah"
}

yields the following triples:

_:b0 <bar:456> "blah" . <---- expected <http://ex.com/bar#456>
_:b0 <http://ex.com/foo#123> "baz" .

But in LD 1.0, it yields:

_:b0 <http://ex.com/bar#456> "blah" . <----- works as expected
_:b0 <http://ex.com/foo#123> "baz" .

which is what you expect.

[pchampin]

That's right, simple term definitions and expanded term definitions behave differently regarding @prefix:

• in expanded term definitions, @prefix defaults to false (but can be explicitly overriden),
• in simple term definitions, the implicit @prefix value depends on the last character of the IRI.

IIRC, the feeling of the WG was that the default value of @prefix should have always been false (hence the default for expanded term definitions). But on the other hand, JSON-LD 1.0 has set the expectation that simple term definitions could be used to define prefixes, hence the special case for simple term definitions.

Standardization is about compromise :)

[wdduncan]

@pchampin Thanks for the feed back! Setting the @prefix to true in an expanded term definitions allows use of the underscore ("_") at the end IRIs, which is very important for the OBO community.

For example:

{
  "@context":
  {
    "foo": "http://ex.com/foo#",
    "bar": {
      "@prefix": true,
      "@id": "http://ex.com/bar_"
    }
  },
  "foo:123": "baz",
  "bar:456": "blah"
}

yields:

_:b0 <http://ex.com/bar_456> "blah" .
_:b0 <http://ex.com/foo#123> "baz" .

It would be nice to have a global way to set @prefix to true, rather than having to use expanded term definitions for all OBO IRIs. Any plans to make this possible?

[iherman]

This issue was discussed in a meeting.

• RESOLVED: <code>@prefix</code> flag is a good idea, but a new feature that will be added to a future version with the hope that this will come quickly, given new W3C process options

View the transcript

@prefix
Rob Sanderson: https://github.com/w3c/json-ld-syntax/issues/329
Harold Solbrig: We talked about this last week.
… There is a whole community out there that uses JSON-LD mainly for prefix mgmt.
… Their prefixes are non-standard.
… The @prefix feature we put in broke their stuff a while back, the only noticed recently when things started breaking.
… This used to work in JSON-LD 1.0, but breaks in 1.1. Sometimes they treat it as regular JSON.
… I suggested @prefix true in root making all terms prefixes.
… We’re not going to get that one in without going back to WD.
… Alternative solution, make it an API parameter to mark all terms as prefixes. Problem: this changes the semantics. But community would be happy with it.
… Alternative 2: we can add _ (and possibly more characters) to gen-delim list.
… We don’t want to loose this community.
Rob Sanderson: Should there be syntactic sugar to prefix? And what about backwards-compatibility with 1.0?
Gregg Kellogg: If you use an expanded term def without @prefix true, we don’t …
Rob Sanderson: We gave people the ability for people using non-gen-delim as last character a way to still force the term as a prefix.
… The change is in the context, which no one would be processing as JSON?
Harold Solbrig: Yes, they process the context as just JSON. Mainly for prefix-management.
Benjamin Young: I don’t want to change the language to match the translation book.
… We are seeing this pattern happening in other communities, where people are processing JSON-LD as JSON.
… It’s a space we need to watch. People want a minimal set of tooling to work with contexts without going all into RDF land.
Harold Solbrig: +1 on bigbluehat – folks are thinking about using context files as declarative mappings as well
Rob Sanderson: This looks to me like a new feature.
… Unless we agree that this is something is broken, we shouldn’t go back to WD and go back again.
Harold Solbrig: Are there any options I mentioned that doesn’t require us to go back to WD?
… Can we just add the option? Or add something to the gen-delim list? Do these require going back to WD?
Rob Sanderson: Yes, it makes current tests invalid and changes behaviour.
Pierre-Antoine Champin: I agree that it would be a normative change. We could argue that we don’t change the intention. Would content-negotiation be an alternative option for this community?
… Would not be possible if hosted on GitHub pages, which I think it is.
Harold Solbrig: I’m scared of the outrage of JSON-LD being the URL police. They are reasonable, but we have to step in an be nice, because I’m scared that they will step away from JSON-LD if we can’t come up with something.
Gregg Kellogg: This is about terms, not URLs. For example, in Turtle prefix are unambiguous, but that’s not the case in JSON-LD. I’m sympathetic with what they are going through, but the WG has been open for a while, so they could/should have listened to what is going on.
Rob Sanderson: There is a solution that would make it work, which is to put prefix: true on all prefixes. I think this is a valid answer because we did the same with another community for @propagates. The solution was to pick one of the two options, and one of the option was implicit, and the other option requires another explicit keyword.
… I suggest that we say that they have to make prefixes explicit.
Harold Solbrig: I don’t think it’s going to fly for them. They have another use for the contexts and reading them as JSON. This would triple the size of their file, which may be a problem for them.
… I have to leave now…
Benjamin Young: I think this is the JSON-LD versus the world question, and how we best interface with the various communities.
… We are highlighting several problems with different communities.
… I would love there to be other options next to us saying we’re out of time.
… Harold is probably right that we’re going to lose them.
… We need to have a better answer for the future of JSON-LD.
… For resolving issues, such as is going on now with RDF.
Ivan Herman: Let’s be careful with this discussion.
… The RDF community has lost activity, but this is a different case.
… For cases like these we need a strict deadline, saying when we do a release.
… There were discussions in Fukuoka which means that it would be possible to introduce a different kind of processing for an existing spec.
… Where a new feature could be added in a much shorter round.
… What would happen here, if we already had a rec, and this issue came in, we go to something like a CR, that has to show implementations, and can be added to the recommendation.
… What is happening now, there will be a vote on this new process soon-ish.
… I would expect it to be accepted. Then we have to understand how this affects existing specs, and we have to decide if there is a community out there that wants to maintain JSON-LD like this.
… It means that member companies to maintain a WG, which not all companies will want to do.
… If there had been such a process around at the RDF spec time, I’m not sure such a process would have been applied for RDF, as the community became less active.
… There are high probabilities that the AC meeting in Korea will not happen because of the coronavirus, so this may slow down the discussion:-(.
Gregg Kellogg: A living standard-type process would be good. JSON-LD is substantially different than the RDF community, because there are less things people disagree on. We shouldn’t wait for 3-5 years for future changes.
Ivan Herman: The goal of this new process would be to avoid gaps of several years.
… The current process slows down things.
Benjamin Young: People want two things: hope and a path. Our current conversations go away from that, when we say that the time is up.
… We should tell people what they should do when we say time is up, instead of just saying ‘defer’.
… Because this shrinks the size of the community, and we should give people hope.
Rob Sanderson: The value of the current process is about scoping.
… If we didn’t have this feature scope, we would never finish, because new good ideas would always come.
Gregg Kellogg: +1 to azaroth
Rob Sanderson: For new product releases, you have to define the set of features a product supports.
… To me, the prefix block would be a good feature to support in the future, but can not do at the moment.
Pierre-Antoine Champin: The global flag would be an easy thing to implement, which we could do as implementors, even if it is not supported formally.
Rob Sanderson: Is it actually the best solution?
Gregg Kellogg: The advantage of having @prefix of context level instead of term level, is that the processor would do the right thing when it sees it.
… We definitely need some messaging to the community on what the processing is.
Ivan Herman: We should decide now on a resolution.
Proposed resolution: @prefix flag is a good idea, but a new feature that will be added to a future version with the hope that this will come quickly, given new W3C process options (Rob Sanderson)
Gregg Kellogg: +1
Rob Sanderson: +1
Ruben Taelman: +1
David I. Lehn: +1
Tim Cole: +1
Pierre-Antoine Champin: +1
Ivan Herman: +1
Benjamin Young: +1
Resolution #3: @prefix flag is a good idea, but a new feature that will be added to a future version with the hope that this will come quickly, given new W3C process options

[wdduncan]

@iherman Thanks for the info!

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

Prefixes
Rob Sanderson: https://github.com/w3c/json-ld-syntax/issues/329
Harold Solbrig: I put in a -1 as there is quite a bit of work the community will need to do to get around the issue, and they’re not anxioius to do it.
… Its not that it won’t be fixed, but that we may need to wait a while.
… One of the members went over previous 1.0 releases to find out where they were bit.
… I hate being obnoxious about this, but I find myself representing this group, and discovering that we can’t use what’s there today. It was flaws in our own codebase which hid this.
Gregg Kellogg: Need to stop adding things in order to have a release, but shouldn’t stop all work and the new process should let us move more swiftly
… Of all the proposed changes, the prefix wrapper or the prefix: true would solve the issue.
… Or, if we could just add “_” to the list of gendelims that would go a long way towards helping.
… I’ll need to go back to see how strongly the group feels.
Rob Sanderson: I don’t believe we can just add “_” to gendelim, as it would mean changing the algorithm and tests, which is what we determined to be the criteria for normative changes.
Harold Solbrig: That’s unfortunate. The only other thing I can think about is if we can get the library authors to put in a non-standard workaround.
… Otherwise, we’re putting out a spec that has so much promise but could be unusable by this community.
Ivan Herman: I think it’s another CR; it may change implementations that have already passed all the tests. It’s a changing feature, even if it is minor, but formally it is changing an existing feature.
… The previous changes were addressing bugs.
Rob Sanderson: This is an intended consequence that the community is asking us to walk back, or to give them more control in managing prefixes.
… One concern I have about adding “_”, is that while a lot of systems use camel-case, a number also use snake_case.
… This would lead to exactly the same problem we were trying to fix.
Harold Solbrig: Unfortunately, the fix in 1.1 is to have the ability to say I intend to be a prefix, and the syntax requires major structural edits.
… I understand the issue, but I need to consider further and discuss with the community.
… That might be a way to convince them.
Ivan Herman: To discuss the possibilities, we have to realize that if we go back to a WD, we run some risk, as there is no guarantee that the AC will agree to an extension of the charter. It may not be high, but it’s non-zero.
Harold Solbrig: I’m split on the issue myself.
… I’ll see if the number of libraries they use is limited enough that they can maintain forks.
… How far out might it be before it can be addressed formally?
Ivan Herman: I would be hopeful that the process changes can be done relatively quickly; not 2 years.
… The processes update is ongoing, and we’d need to have a discussion on turning the group into a maintenance group which could do such a change in 1-2 months.
… Such a change would be backwards-compatible, so it would make it easier to do.
… It means that JSON-LD becomes a kind of continuously evolving standard, similar to HTML5.
… They added an element to HTML5 fairly smoothly.
Harold Solbrig: I’m going to say that I don’t want to stop things, so I’m willing to revise my vote.
Ivan Herman: -1 is not a-priori a formal objection.
… At some point in time the new process will go to the AC for a vote, and there may be people that won’t do that. So any AC members here might want to speak up about that.
Gregg Kellogg: The CG might make a parallel extension to the spec
… prior to this group there was interest in updating towards a 1.1
… maybe something could be done there to hang your hat on that describes extensions to the spec
… might be obsolete if the process changes
Harold Solbrig: There’s enough new stuff in 1.1 that it’s sparking new ideas, and the CG might be a good way to incubate these types of changes.
David I. Lehn: I’m pretty sure that people implementing it are happy to put in new features, even if it’s not in 1.1. I’m worried about people starting to use proposed features that don’t survive.
Harold Solbrig: The workaround right now is very minimal. We just added a “prefix” option defaulting to false, but if it’s true allows any term to be used as a prefix.
… The huge cost would be to change the resources themselves.
David I. Lehn: Adding flags might hurt interoperability.
… Even if we don’t do this in 1.1, it would be good to agree on a direction.
Gregg Kellogg: https://github.com/json-ld/json-ld.org/issues
Rob Sanderson: It would be valuable if there were more people than just hsolbrig; if more people could join the CG and we can have a discussion in public.
Harold Solbrig: There are several people raving on email that might join.
Rob Sanderson: One of the easiest ways to justify the new process is to be able to point to a discussion that shows why its important to be able to move quickly to support the community.
… This would be good to convince the AC that we should move to such a process.
Harold Solbrig: These people are interested in learning more about the process. Getting them engaged can help.
Rob Sanderson: I think one of your proponents is at Lawrence Berkeley labs, who are W3C members.

[matentzn]

Are there any updates on this issue?

[gkellogg]

The little activity in the recommendations is mostly directed at errata and test issues. This feature may be considered for the next release cycle, depending on what the Maintenance Group prioritizes.