Closed eroux closed 4 years ago
In JSON-LD 1.1 you can say that a term should not be used for constructing compact IRIs, by defining them using an expanded term definition. So, you might define your context as:
{
"@context": {
"@version": 1.1,
"bdan": {"@id": "http://purl.bdrc.io/annotation/"},
"bdac": {"@id": "http://purl.bdrc.io/anncollection/"}
},
...
}
See Compact IRIs:
In JSON-LD 1.1, terms may be chosen as compact IRI prefixes when compacting only if a simple term definition is used where the value ends with a URI gen-delim character, or if their expanded term definition contains a
@prefix
member with the value true.
I'm trying to make a serialization of a web annotation collection model into JSON-LD, but it seems it's not really possible with the current JSON-LD algorithm.
My understanding (and I'm happy to be contradicted on that) is that the web annotation spec is quite clear that only rfc3987-compliant IRIs should be used in objects, it defines the term IRI this ways and refers to it constantly. There is no mention at all of "compact IRI". This means (I believe) that IRI should never be compacted when they are in values.
Now, in the system I'm building I have a prefix that I'm using for ttl for annotation, annotation collections, etc.
So, I believe that when the compaction algorithm compacts any object's IRI into a compactIRI, it breaks the web annotation serialization. For instance in my system I have the prefixes
for annotations and annotation collections. But if I apply a serialization of my model to a page for instance, I'll get something like (slightliy modified Example 40):
which is normal according to the JSON-LD spec, but is, as I understand, an invalid serialization of the web annotation. Plus, even if it's invalid, the spec is so unclear that a compactIRI could be used that all pure json implementations of web annotation readers will probably ignore that possibility.
So, in short: is it possible to add an option to the compaction algorithm not to use compactIRIs in values?