parser handling of @id vs id properties

[teledyn]

This is adapted from bad json-ld found in the wild (but on an important enterprise website) where Google is able to make sense in the SDTT, but our parser is making an unfortunate mistake ...

The source json block is lacking @id, and in these cases I add one set to the url of the page before parsing; the json-ld is parsed by json.loads(), I add js['@id'] = response.url + tag and then json.dumps() into js_text -- what follows is the rdflib transform:

from rdflib import Namespace, Graph, RDF, XSD, URIRef, plugin, Literal
INFO:rdflib:RDFLib Version: 4.2.2
from rdflib.serializer import Serializer
js_text = """{"description": "No description", "width": 640, "@id": "https://www.example.com/customer-reviews/#SA_VideoObject", "id": "7PYqBSgCKVBNeAPERGpSBs", "height": 360, "duration": "T1M32S", "uploadDate": "2019-01-03T16:17:49.000Z", "keywords": "test", "@context": "http://schema.org/", "embedUrl": "https://play.content.com/7PYqBSgCKVBNeAPERGpSBs", "thumbnailUrl": "https://play.content.com/7PYqBSgCKVBNeAPERGpSBs.jpg", "@type": "VideoObject", "name": "G2C Example"}"""
g = Graph().parse(data=js_text, format="json-ld")

notice that the source json-ld has no context property, and has it's own id property that is just a unique string, so it is already a gamble what rdflib might do with it ;) What happens, though, is the @id property is dropped, and the id property is mistakenly taken as the @id, and lacking the protocol and host, is assumed to be a file://... item:

<file:///home/garym/Work/SchemaCrawler/7PYqBSgCKVBNeAPERGpSBs> <http://schema.org/width> "640"^^<http://www.w3.org/2001/XMLSchema#integer> .
<file:///home/garym/Work/SchemaCrawler/7PYqBSgCKVBNeAPERGpSBs> <http://schema.org/duration> "T1M32S" .
<file:///home/garym/Work/SchemaCrawler/7PYqBSgCKVBNeAPERGpSBs> <http://schema.org/embedUrl> <https://play.content.com/7PYqBSgCKVBNeAPERGpSBs> .
<file:///home/garym/Work/SchemaCrawler/7PYqBSgCKVBNeAPERGpSBs> <http://schema.org/name> "G2C Example" .
<file:///home/garym/Work/SchemaCrawler/7PYqBSgCKVBNeAPERGpSBs> <http://schema.org/thumbnailUrl> <https://play.content.com/7PYqBSgCKVBNeAPERGpSBs.jpg> .
<file:///home/garym/Work/SchemaCrawler/7PYqBSgCKVBNeAPERGpSBs> <http://schema.org/height> "360"^^<http://www.w3.org/2001/XMLSchema#integer> .
<file:///home/garym/Work/SchemaCrawler/7PYqBSgCKVBNeAPERGpSBs> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema.org/VideoObject> .
<file:///home/garym/Work/SchemaCrawler/7PYqBSgCKVBNeAPERGpSBs> <http://schema.org/description> "No description" .
<file:///home/garym/Work/SchemaCrawler/7PYqBSgCKVBNeAPERGpSBs> <http://schema.org/uploadDate> "2019-01-03T16:17:49.000Z"^^<http://schema.org/Date> .
<file:///home/garym/Work/SchemaCrawler/7PYqBSgCKVBNeAPERGpSBs> <http://schema.org/keywords> "testing" .

So the source json is incorrect as far as schema.org or json-ld goes, however the Google SDTT extracts semi-correctly:

@id	: 
https://www.example.com/customer-reviews/7PYqBSgCKVBNeAPERGpSBs

but my question is why was @id ignored and id taken as the base node? Is this expected?