EOL JSON-LD not valid

[rdmpage]

The JSON-LD returned by trait bank fails when parsed by the JSON-LD playground, see http://tinyurl.com/hfoos6p

Here's an example http://eol.org/api/traits/10692652. JSON-LD playground complains about "@id": 10692652, an @id needs to be a string (ideally a URI). I would have thought that "http://eol.org/pages10692652" was the obvious value. Fixing that leads to a second problem,

"vernacularNames": [
      {
        "@language": "en",
        "@value": "Rio Orinoco Spinetail",
        "gbif:isPreferredName": true
      }
    ]

causes the message Invalid JSON-LD syntax; an element containing "@value" may only have an "@index" property and at most one other property which can be "@type" or "@language".

Deleting "gbif:isPreferredName": true fixes that. Once these bugs are fixed, the JSON-LD can be parsed OK.

{
  "@context": {
    "@vocab": "http://schema.org/",
    "dwc:taxonID": {
      "@type": "@id"
    },
    "dwc:resourceID": {
      "@type": "@id"
    },
    "dwc:relatedResourceID": {
      "@type": "@id"
    },
    "dwc:relationshipOfResource": {
      "@type": "@id"
    },
    "dwc:vernacularName": {
      "@container": "@language"
    },
    "eol:associationType": {
      "@type": "@id"
    },
    "rdfs:label": {
      "@container": "@language"
    },
    "dc": "http://purl.org/dc/terms/",
    "dwc": "http://rs.tdwg.org/dwc/terms/",
    "eolterms": "http://eol.org/schema/terms/",
    "eol": "http://eol.org/schema/",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "gbif": "http://rs.gbif.org/terms/1.0/",
    "foaf": "http://xmlns.com/foaf/0.1/"
  },
  "@type": "DataFeedItem",
  "dateModified": "2016-09-22",
  "item": {
    "@id": 10692652,
    "@type": "dwc:Taxon",
    "scientificName": "Synallaxis beverlyae",
    "dwc:taxonRank": "species",
    "dwc:parentNameUsageID": "http://eol.org/pages/15003",
    "potentialAction": {
      "@type": "EntryPoint",
      "target": {
        "@type": "Related",
        "url": "http://eol.org/pages/10692652",
        "actionPlatform": [
          "http://schema.org/DesktopWebPlatform",
          "http://schema.org/IOSPlatform",
          "http://schema.org/AndroidPlatform"
        ]
      }
    },
    "sameAs": [
      "http://www.birdlife.org/datazone/speciesfactsheet.php?id=32678",
      "http://lod.taxonconcept.org/ses/voUQo.html",
      "http://www.iucnredlist.org/apps/redlist/details/22736309",
      "http://www.iucnredlist.org/apps/redlist/details/22736309",
      "http://en.wikipedia.org/w/index.php?title=Río_Orinoco_Spinetail"
    ],
    "vernacularNames": [
      {
        "@language": "en",
        "@value": "Rio Orinoco Spinetail",
        "gbif:isPreferredName": true
      }
    ],
    "traits": [

    ]
  }
}

[frmichel]

Is there anyone at EoL reading these issues?

As far I understand from the trait bank pages, it is only accessible through this JSON-LD API. But any JSON-LD parser will fail trying to parse this flawed JSON-LD content.

Does anyone care? How to spur new usages of the trait bank if its API is not complying with standards?

Please help.

Franck.

[jhammock]

Please hang in there, @frmichel! The pseudo-JSON-LD is a relic of EOL v2. We should have some of the v3 services up in beta shortly, ready for feedback.

[frmichel]

@jhammock this is great news. Any mailing list or github issue where I should look at for updates about this?

The pseudo-JSON-LD is a relic of EOL v2

I get that, only it would be fine if you guys could reply to the open issues about this topic, even if this is just to say "hey be patient, we are working on that" ;)

Franck.

[jhammock]

@jar398 could you please page @frmichel to the appropriate repository when you start standing up the services? We are finally speaking with neo4j today so should have that license figured out shortly.

[jar398]

Not sure what you mean by ''standing up the services"? The queries we talked about can run against your existing neo4j instance. The EOL neo4j already has the service that is needed (Cypher transactional endpoint), so what remains to do is neo4j account setup and query documentation (in progress). Unless I've missed some important piece, which is entirely possible. Our Feb 12 email exchange about there being no need for 'shim' services may be relevant - if access is via Cypher, then there is no other 'service' to 'stand up'.

[jhammock]

-> account setup, sorry

[jar398]

Great. I don't think we'll need to rehearse account setup, and it doesn't matter to me whether I do it or I give instructions for someone else to do it. Just let me know when EE is ready.

I can get started on a repository for documentation around user setup, and about other things I'm doing, regardless.