Should we `@type` all nexml objects in the JSON-LD?

[cboettig]

While not required, json-ld encourages explicitly declaring a @type on all objects.

NeXML relies on declaring an xsi:type as a nex:something on certain elements, like characters, while most elements do not get an explicit type (although of course the NeXML schema defines types for them). e.g. an otu node does not get an xsi:type attribute generally.

In my original prototype, I added a type to all json elements based on the node name if an xsi:type was not explicitly declared, e.g.

 "otu": [
        {
          "@type": "otu",
          "@id": "t1",
          "label": "species 1"
        },
        {
          "@type": "otu",
          "@id": "t2",
          "label": "species 2"
        },
        {
          "@type": "otu",
          "@id": "t3",
          "label": "species 3"
        },

This raises a question about how to round-trip back into XML. To match the input document, we'd probably want to drop these; but we would need to know if the @type came from an explicit declaration or not. (We could probably tell because the value in the explicit cases tends to include a namespace, e.g. xsi:type="nex:RestrictionSeqs").

However, my instinct is that we should just let the JSON-LD more closely match the original NeXML; and only declare an @type if the XML element declares an xsi:type, and otherwise leave things without an explict @type (i.e. stop doing what I show above). This probably makes more sense than making up @type values for everything on the fly or trying to encode the literal schema types onto every element.

@gaurav @rvosa @hlapp Agree? thoughts?

[rvosa]

If the general goal is concise, idiomatic JSON, then the @type should go. The xsi:type declarations are used where they are in order to disambiguate between polymorphies, so, in places where they are NOT used (like here, on an otu) you can be pretty sure that omitting them is not going to cause ambiguities e.g. when roundripping.

On Fri, Dec 15, 2017 at 7:54 PM, Carl Boettiger notifications@github.com wrote:

While not required, json-ld encourages explicitly declaring a @type on all objects.

NeXML relies on declaring an xsi:type as a nex:something on certain elements, like characters, while most elements do not get an explicit type (although of course the NeXML schema defines types for them). e.g. an otu node does not get an xsi:type attribute generally.

In my original prototype, I added a type to all json elements based on the node name if an xsi:type was not explicitly declared, e.g.

"otu": [ { "@type": "otu", "@id": "t1", "label": "species 1" }, { "@type": "otu", "@id": "t2", "label": "species 2" }, { "@type": "otu", "@id": "t3", "label": "species 3" },

This raises a question about how to round-trip back into XML. To match the input document, we'd probably want to drop these; but we would need to know if the @type came from an explicit declaration or not. (We could probably tell because the value in the explicit cases tends to include a namespace, e.g. xsi:type="nex:RestrictionSeqs").

However, my instinct is that we should just let the JSON-LD more closely match the original NeXML; and only declare an @type if the XML element declares an xsi:type, and otherwise leave things without an explict @type (i.e. stop doing what I show above). This probably makes more sense than making up @type values for everything on the fly or trying to encode the literal schema types onto every element.

@gaurav https://github.com/gaurav @rvosa https://github.com/rvosa @hlapp https://github.com/hlapp Agree? thoughts?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cboettig/nexld/issues/14, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGf-kB4G36H2FqopdFi1YltsS41wWlUks5tAsBngaJpZM4RD3av .

[cboettig]

@rvosa thanks, this sounds good to me. Quick question on prefixes on the types: it looks like you explicitly namespace the values of the xsi:types, e.g. nex:IntTree. When we convert to JSON-LD, these are expanded appropriately, e.g.

"@id": "http://example.org/tree3",
            "@type": [
              "http://www.nexml.org/2009/IntNetwork"
            ],

and when we compact the JSON-LD, the prefix compacts completely, since it is defined as the @vocab (default namespace), so this just becomes "type": "IntNetworkl". This means that in a roundtrip, nex:IntNetwork will just be IntNetwork in the output XML. Is that a problem? (Any other prefix will remain in place ,e.g. xs:Date etc). (Note we're map the @vocab JSON-LD value to nexml element xmlns:, i.e. the default namespace(?))

[rvosa]

I am not sure. I vaguely recall that the prefix is not necessary if a default namespace is in effect (i.e. xmlns=<uri>) so it might be syntactically valid. What does the validator say?

On the other hand, what will the file readers say that parse NeXML? I don't discount the possibility that they have the nex: prefix hardcoded. I may not have been above that myself at some points to be quite honest.

How ugly would it be to keep them?

On Tue, Dec 19, 2017 at 6:37 AM, Carl Boettiger notifications@github.com wrote:

@rvosa https://github.com/rvosa thanks, this sounds good to me. Quick question on prefixes on the types: it looks like you explicitly namespace the values of the xsi:types, e.g. nex:IntTree. When we convert to JSON-LD, these are expanded appropriately, e.g.

"@id": "http://example.org/tree3", "@type": [ "http://www.nexml.org/2009/IntNetwork" ],

and when we compact the JSON-LD, the prefix compacts completely, since it is defined as the @vocab (default namespace), so this just becomes "type": "IntNetworkl". This means that in a roundtrip, nex:IntNetwork will just be IntNetwork in the output XML. Is that a problem? (Any other prefix will remain in place ,e.g. xs:Date etc). (Note we're map the @vocab JSON-LD value to nexml element xmlns:, i.e. the default namespace(?))

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cboettig/nexld/issues/14#issuecomment-352644991, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGf-o_ZaBbbFDmq_-x8RUj0nTsDUo-4ks5tB0uOgaJpZM4RD3av .

[cboettig]

The validator is happy without it, which makes sense based on the default namespace.

I think we can just intercept any type attributes and add a nex: prefix if they do not already have a prefix to be safe. Thanks.