Open hsolbrig opened 4 years ago
This issue was discussed in a meeting.
@prefix=true
globally,@prefix=false
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
Does not?
In general, can someone verify that ALL of the behaviors below conform to the spec?
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
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.
In general, can someone verify that ALL of the behaviors below conform to the spec?
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
).
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.
@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.
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.
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.
The NAMESPACE_ prefix works fine in the JSON-LD 1.0 playground. What changed?
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
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.
That's right, simple term definitions and expanded term definitions behave differently regarding @prefix
:
@prefix
defaults to false
(but can be explicitly overriden),@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 :)
@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?
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
@prefix
@prefix
feature we put in broke their stuff a while back, the only noticed recently when things started breaking.@prefix
true in root making all terms prefixes.@prefix
true, we don’t …@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.@prefix
of context level instead of term level, is that the processor would do the right thing when it sees it.@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)@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@iherman Thanks for the info!
This issue was discussed in a meeting.
Are there any updates on this issue?
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.
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?