PrefixMap.addAll should return this about rdf-ext

[jlanza]

Could you provide an example on how to use the PrefixMap. I have a map but when serializing the url are not shriked. Should I do it manually?
The issue is that I want my data to be included with prefixes and then when printing or serializing choose wether it is extended or not. Or even create the appropiate options for it based on the map used.

I'm thinking on using json-ld.js in conjunction with your serializer.

[ktk]

@jlanza can you provide some sample code of what you have?

[bergos]

At the moment the N3 serializer is the only one that supports exporting the prefix map. Importing works with the N3 and JSON-LD parser.

The JSON-LD serializer exports triples in flat form. Because JSON-LD can be written in different forms, the jsonld.js should be used to convert the JSON to the target form.

Maybe we can add a method to convert a prefix map to a JSON-LD context to compact the JSON.

[jlanza]

For the moment I think I'm going to use the following function to create namespaces based on the prefixMap. This way the creation of the nodes is always going to be in long form:

var namespace = function(nsuri) {
  return function(ln) {
    return new rdf.createNamedNode(nsuri + (ln != null ? ln : ''));
  };
};

var RDF = namespace(prefixMap["rdf"]);
var type = RDF("type");

But if I have time I will fork the json-serializer in order to include the prefix map and extend any reference that is shortened (shrink). Do you think it is ok to use another element in options object like you do in N3 parser?

[bergos]

To avoid code duplication and option handling for jsonld.js I think the way to go would be a method to write code like this:

serializer.serialize(graph).then(function (json) {
return jsonld.promises().compact(json, serializer.prefixToContext(graph))
})

That would allow to use the full power of jsonld.js without the need to handle all possible options and methods in the serializer.

[jlanza]

Yes... You're right. This is more or less what I was thinking. But does the Graph contains the prefixMap of the environment?
Besides the other issue is that for instance if I have my entities defined shrinked, then the serializer should take the prefixMap in order to extend them. What I mean is:

var node1 = rdf.createNamedNode("rdf:type");
var node2 = rdf.createNamedNode("http://www.w3.org/1999/02/22-rdf-syntax-ns#type");

both node1 and node2 should be the same, considering the prefixMap the environment has implemented.

[ktk]

From how I remember the spec this would not work as rdf:typeneeds to be resolved manually. I was always annoyed by that as IMHO one should be able to specify the prefixMap for the whole environment and then the graphs should know it and automatically resolve it where necessary.

[jlanza]

I have the same thoughts as you and that's what my question was about!!! ;) Not just for rdf:type but for any other. It would be great to have entities written in an easy way. This is why I took the approach of the namespace function above.

Besides concerning the serialization and the context retrieval from the prefixMap I have done the following.

var context = {};
for (var prefix in myprofile.prefixes) {
  if (typeof myprofile.prefixes[prefix] === 'function') {
    continue;
  }
  context[prefix] = myprofile.prefixes[prefix];
}

If you'd like I can include a function in PrefixMap and TermMap as .toJSON() so you get rid of the functions and then this object can be used to create context, etc.

[ktk]

Examples of how it was ment to be can be found in RDF Interfaces spec.

My idea went one step further: I started creating a 1:1 mapping of prefixes I use based on RDFa initial contexts, see https://github.com/uduvudu/uv-context for more information. My idea was then to simply load that (for example as a node module) into my code so I could directly use the prefixes in all my code. But I never finished the module-work.

[jlanza]

Looks interesting... I'm forking and incluing the above code.. Then it's up to you to accept ;)

[ktk]

@bergos @tpluscode is this issue still relevant here? From my understanding this would be something for RDF Environment.

[ktk]

Prefix-maps are legacy feature and no longer supported in the current version. There is currently no replacement.