fiware / context.orion-ld

Context Broker and CEF building block for context data management which supports both the NGSI-LD and the NGSI-v2 APIs

Orion Context Broker (with Linked Data Extensions)

This project is part of FIWARE. For more information check the FIWARE Catalogue entry for FIWARE Core Context Management.

Issues on this projects can be reported as github issues, while questions are preferred on Stack Overflow, using the tag fiware-orion.

The latest release of Orion-LD is 1.6.0 from July 2024

Orion-LD is a Context Broker and CEF building block for context data management, implementting both the NGSI-LD API and the NGSIv2 API. It is currently a fork of the original Orion Context Broker extending support to add NGSI-LD and linked data concepts. Orion-LD follows the ETSI specification for NGSI-LD and has been tested to be a stable and fast NGSI-LD broker with near compliance to the version 1.6.1 of the NGSI-LD API specification (and some features from newer releases).

License

Orion-LD is licensed under Affero General Public License (GPL) version 3.

Further information on the use of the AGPL open source license

Are there any legal issues with AGPL 3.0? Is it safe for me to use?

There is absolutely no problem in using a product licensed under AGPL 3.0. Issues with GPL (or AGPL) licenses are mostly related with the fact that different people assign different interpretations on the meaning of the term “derivate work” used in these licenses. Due to this, some people believe that there is a risk in just using software under GPL or AGPL licenses (even without modifying it).

For the avoidance of doubt, the owners of this software licensed under an AGPL-3.0 license wish to make a clarifying public statement as follows:

Please note that software derived as a result of modifying the source code of the software in order to fix a bug or incorporate enhancements IS considered a derivative work of the product. Software that merely uses or aggregates (i.e. links to) an otherwise unmodified version of existing software IS NOT considered a derivative work.

Contribution to Orion-LD

Anyone wishing to contribute to Orion-LD, be it fixing/adding documentation, tests, source code, all types of contributions are welcome. For source code contributions, please see the Contribution guidelines.

General Information on NGSI-LD

NGSI-LD is an an extended subset of JSON-LD for use with context management systems. Its payloads are encoded as linked data using JSON.

The NGSI-LD Specification is regularly updated and published by ETSI. The latest specification is version 1.8.1, published in March 2024. The next release, version 1.9.1, is expected for September/October 2024·

A few presentations on NGSI-LD:

• NGSI-LD Overview
• NGSI-LD in 30 min
• NGSI-LD in a Nutshell

Examples of NGSI-LD payloads can be found in ETSI. See also the OpenAPI Specification of NGSI-LD.
That is for version 1.7.1 of the NGSI-LD API specification.
We're currently working on updating this to v1.8.1, ETA: Dec 2024.

If you are not sharing your data across systems and have no need for linked data concepts, then the current stable version of NGSI (NGSI-v2) is more than sufficient. If so, please use the original Orion instead of Orion-LD (note that Orion-LD is not up-to-date with Orion in terms of NGSI v2).

📚 Documentation	🎓 Academy	quay.io

NGSI-LD Context Broker Feature Comparison

An Excel file detailing the current compatibility of the development version of the Orion-LD Context Broker against the features (up to v1.8.1) of the API specification can be downloaded here.

Test and Deployment of Orion-LD

If you want to start testing Orion-LD, the most common option is to use Docker. There are a number of docker images to choose from.

If you (at your own risk) want to evaluate the bleeding edge development changes, you can use the latest image: docker run fiware/orion-ld:latest or better: use docker compose to run it.

The use of the "latest" tag is NOT RECOMMENDED, as it keeps changing. Please don't use it. It's solely meant for internal testing. The recommendation is to use the newest fixed tag you find and stick to it until you have need for some newer feature/fix and then change to that newer fixed tag. Every merged pull request results in a new fixed tag in dockerhub/quay.io.

Please note that for production and/or performance implementations, there is a thorough guide for that right here

If you want to use a more stable image, the latest release (as of July 2024) is 1.6.0

docker run quay.io/fiware/orion-ld:1.6.0

Please check quay.io or dockerhub for other releases.

Documentation:

• Guide to NGSI-LD entities and attributes
• Guide to the JSON-LD @context
• Installation Guide
• Quick Start Guide
• External Libraries
• Temporal Representation
• The Broker as Context Server
• Roadmap

A Test Suite for NGSI-LD compliant brokers can be found here. This test suite is deprecated in favor of the newer ETSI NGSI-LD API Conformance Test Suite. (Orion-LD passes about 95% of the test cases of this older deprecated test suite.)

About the ETSI funded conformance test suite, a third TTF (Testing Task force) is currently in progress, to improve on overall coverage and to aggregate conformance tests for distributed operations. This third TTF is expected to finish in February 2025 and by then, the ETSI NGSI-LD conformance test suite should be fully operational, and thus test results for Orion-LD can and will be published.

context.orion-ld's Issues

options=keyValues

The keyValues option is only implemented for GET operations.
Do we want it for POST/PATCH as well?

UPDATE, Jan-29 2022:

This issue just got more relevant.
There is a push from the FIWARE Foundation for the NGSI-LD API to support key-values for update and perhaps even create operations.

A proposal has been prepared for ETSI ISG CIM and will be presented abd discussed in the NGSIO.-LD API call on Feb 1 2022.
Also, a first "pilot" for the request "PATCH /ngsi-ld/v1/entities/{entityId}/attrs/{attributeName}" is under implementation.

Point to the official ETSI Core @Context

The official Core @context is at

http://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld

Please modify your code to point to it and remove the old forge.etsi....

Thanks

Docker-compose: Startup Error (cannot connect to mongo - doing 100 retries with a 1000 microsecond interval)

Hi,
I just updated the docker container. Now broker is not starting due to some connection problems to mongo db.
time=Wednesday 15 May 08:30:35 2019.273Z | lvl=ERROR | corr=N/A | trans=N/A | from=N/A | srv=N/A | subsrv=N/A | comp=Orion | op=mongoConnectionPool.cpp[152]:mongoConnect | msg=Database Startup Error (cannot connect to mongo - doing 100 retries with a 1000 microsecond interval)
As far as I can see the mongo db is running. Maybe there is something wrong with the new docker image? System is started via docker-compose.

If no Accept header provided --> application/json content shall be provided

The default content to be provided in the absence of an Accept header is application/json

Attributes are not overwritten when append entity attributes

See test at

https://github.com/Fiware/NGSI-LD_Tests/blob/master/contextProvision/append_entity_attrs_test.js#L83

Issues when listing subscriptions

A subscription is created with the following application/ld+json payload:

{"type":"Subscription","@context":"https://schema.lab.fiware.org/ld/context","entities":[{"type":"ParkingSpot"}],"watchedAttributes":["status"],"notification":{"endpoint":{"uri":"http://localhost:1880/notif-LD","accept":"application/ld+json"},"format":"normalized","attributes":["status"]}}

Then a GET /ngsi-ld/v1/subscriptions is issued as follows:

curl -X GET \
  http://localhost:1030/ngsi-ld/v1/subscriptions/ \
  -H 'Accept: application/json' \
  -H 'Cache-Control: no-cache' \
  -H 'Connection: keep-alive' \
  -H 'Host: localhost:1030' \
  -H 'Link: <https://schema.lab.fiware.org/ld/context>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
  -H 'Postman-Token: 3a91b721-797b-4e7f-8f1a-e07261cfd8c8,053e36cc-29bb-443f-8627-20b8adef1179' \
  -H 'User-Agent: PostmanRuntime/7.13.0' \
  -H 'accept-encoding: gzip, deflate' \
  -H 'cache-control: no-cache'

{
        "id": "urn:ngsi-ld:Subscription:5d13537c8cae7ee10f60ea97",
        "type": "Subscription",
        "entities": [
            {
                "type": "https://uri.fiware.org/ns/datamodels/ParkingSpot"
            }
        ],
        "watchedAttributes": [
            "https://uri.fiware.org/ns/datamodels/status"
        ],
        "notification": {
            "attributes": [
                "https://uri.fiware.org/ns/datamodels/status"
            ],
            "format": "normalized",
            "endpoint": {
                "uri": "http://localhost:1880/notif-LD",
                "accept": "application/ld+json"
            }
        },
        "expires": "2038-01-19T03:14:07Z"
    }

• expires should not be there
• ldContext Mapping should have happened

if a target entity does not exist append entity attributes return 204 instead of 404

Implement urnCheck()

The function urnCheck() in src/lib/orionld/common/urnCheck.cpp only checks that the URN starts with urn:, nothing more.
The rest of the function needs to be implemented.

createdAt / modifiedAt incorrectly reported as invalid

Using

https://raw.githubusercontent.com/FIWARE/dataModels/master/specs/AgriFood/AgriCrop/example-normalized-ld.jsonld

an error is raised

{"type":"http://uri.etsi.org/ngsi-ld/errors/BadRequestData","title":"Attribute must be a JSON object","details":"createdAt"}

createdAt / modifiedAt are not reified properties, thus they are directly the date as string in ISO8601 format

Create Entity with LD Context fails

Error:

{"body": {"details": "https://fiware.github.io/NGSI-LD_Tests/ldContext/testFullContext.jsonld", "title": "failure to create context from URL", "type": "http://example.org/ngsi-ld/errors/BadRequestData"}, "headers": {"connection": "close", "content-length": "188", "content-type": "application/json", "date": "Tue, 20 Nov 2018 16:50:38 GMT"}, "request": {"headers": {"Content-Type": "application/ld+json", "accept": "application/json", "content-length": 307}, "method": "POST", "uri": {"auth": null, "hash": null, "host": "localhost:1030", "hostname": "localhost", "href": "http://localhost:1030/ngsi-ld/v1/entities/", "path": "/ngsi-ld/v1/entities/", "pathname": "/ngsi-ld/v1/entities/", "port": "1030", "protocol": "http:", "query": null, "search": null, "slashes": true}}, "statusCode": 400}

In timestamps trailing timezone `Z` has to be rendered always

When rendering timestamp data, and as per the latest version of the spec the trailing timezone (always 'Z', has to be rendered). This applies for observedAt, createdAt, modifiedAt or any other DateTime attribute.

NGSI-LD subscription constant crashes: "std::bad_alloc"

Hi,
I am trying to get a subscription working for new added data sources. For this I add the following subscription:
{ "id": "urn:ngsi-ld:Subscription:testsubscription", "type": "Subscription", "entities": [ { "type": ".*" } ], "notification": { "format": "keyValues", "endpoint": { "uri": "http://callback_computer:8080/callback" } }, "@context": "https://fiware.github.io/NGSI-LD_TestSuite/ldContext/testFullContext.jsonld" }

From time to time I get a 201 header back with the subscription id as location. Besides the fact that I don't get any callback for new context (don't know why) the orion-ld server, provided as the latest docker image, constantly crashes.
When trying to add the subscription the connection seems to hang up. After a while (ca. 1 minute) the broker has crashed with a "std::bad_alloc" in its log.
Even if I am doing something wrong with the subscription a crash should not happen? Is there any help/tutorial showing ho to get a subscription working with NGSI-LD? I just found the test suite where I copied the subscription example and changed it to mine (as shown above).
Thanks and kind regards,
tank

extra decimals are introduced in GeoCoordinates (longitude)

Entity:

'id': 'urn:ngsi-ld:T_Query:EntityForQuery2345',
    'type': 'T_Query',
    'P100': {
      'type': 'Property',
      'value': 12,
      'observedAt': '2018-12-04T12:00:00',
      'P1_R1': {
        'type': 'Relationship',
        'object': 'urn:ngsi-ld:T2:6789'
      },
      'P1_P1': {
        'type': 'Property',
        'value': 0.79
      }
    },
    'R100': {
      'type': 'Relationship',
      'object': 'urn:ngsi-ld:T2:6789',
      'R1_R1': {
        'type': 'Relationship',
        'object': 'urn:ngsi-ld:T3:A2345'
      },
      'R1_P1': {
        'type': 'Property',
        'value': false
      }
    },
    'location': {
      'type': 'GeoProperty',
      'value': {
        'type': 'Point',
        'coordinates': [-30.01, 75.01]
      }
    }
  };

When retrieved, coordinates are

'value': {
'type': 'Point',
'coordinates': [-30.01, 75.010002]
}

Subscription validation logic is wrong

POST /ngsi-ld/v1/subscriptions/

{
  "id": "urn:ngsi-ld:Subscription:9000",
  "type": "Subscription",
  "entities": [
    {
      "id": "urn:ngsi-ld:T:T1234",
      "type": "T"
    }
  ],
  "notification": {
    "endpoint": {
      "uri": "http://localhost:1234"
    }
  }
}

it fails with

{
    "type": "http://uri.etsi.org/ngsi-ld/errors/BadRequestData",
    "title": "Either 'timeInterval' or 'watchedAttributes' must be present. But not both of them",
    "details": "None of them"
}

But the spec says that watchedAttributes or entities shall be present, so in that case all attributes shall be watched and the subscription shall be created.

Subscriptions: watchedAttributes nor entities arrays can be 0 length

When payload is an empty object append entity attributes shall return 400

See

https://github.com/Fiware/NGSI-LD_Tests/blob/master/contextProvision/append_entity_attrs_test.js#L76

StringFilter on metadata using q instead of mq

To support the following String Filter ...:

GET /ngsi-ld/entities?q=A1.observedAt>2018-09-01T12:00:00

... we will need to modify the current implementation.
observedAt is a metadata and not part of the compound value for A1.
With the current implementation, this would work:

GET /ngsi-ld/entities?mq=A1.observedAt>2018-09-01T12:00:00

But, that doesn't follow the spec of ngsi-ld.

What needs to be done with the current implementation is to treat observedAt, modifiedAt etc as special words and do the lookup in the metadata vector for 'q' String Filters.

When MIME type of content rendered is "application/json" @context shall not be rendered

instead a JSON-LD Link header shall be provided as part of the HTTP response

when an Entity does not incorporate @context then it shall be assigned the default @context

and not the core NGSI-LD @context

https://forge.etsi.org/gitlab/NGSI-LD/NGSI-LD/blob/master/defaultContext/defaultContext.jsonld

Attribute does not exist

From NGSI-LD Test:

1. created entity successfully
   {
   'id': 'urn:ngsi-ld:T:001',
   'type': 'T',
   'P1': {
   'type': 'Property',
   'value': 'Hola'
   }
   }
2. update fails with:
   {
   'P1': {
   'type': 'Property',
   'value': 'Ciao'
   }
   }

Orion-LD returns:
{type: 'http://uri.etsi.org/ngsi-ld/errors/BadRequestData',
title: 'Attribute does not exist',
details: 'P1' }
}
Used docker version. Endpoint : http://loalhost:1026/ngsi-ld/v1/entities/urn:ngsi-ld:T:001
HTTP Method: PATCH
Header: Content-type: application/json

There is something wrong?
Thank you.
Cris

Subscription creation with context in HTTP Link Header

Subscription creation has just been implemented.
However, it works only for Content-Type "application/ld+json", i.e. with the @context in the payload.
Need to accept "application/json" as wel (i.e. @context in the Link HTTP Header).

URI Expansion on attributes for String Filters

String Filters in ngsild need to URI expand the attribute.
E.g. for the string filter ?q=A1.i==12 A1 will be URI expanded to http:/xxx.yyy.zzz/A1 (or any other URI depending on the @context).

But, what happens if an attribute is created with APIv2?
Then its name is actually "A1" in the database and after URI expansion, A1 will not be found.
To fix this, we'd need to know that en entity/attribute has been created with APIv2 and not ngsild and no URI expansion should be done for this entity/attribute.

Certain queries cause the broker to die

by condition over object

https://github.com/Fiware/NGSI-LD_Tests/blob/master/contextConsumption/query_entities_test.js#L98

by condition over observedAt

https://github.com/Fiware/NGSI-LD_Tests/blob/master/contextConsumption/query_entities_test.js#L108

over property of a property

https://github.com/Fiware/NGSI-LD_Tests/blob/master/contextConsumption/query_entities_test.js#L118

etc.

When a subscription is not found error type shall be ResourceNotFound

array of object (URIs) is not supported for relationships

See test at

https://github.com/Fiware/NGSI-LD_Tests/blob/master/contextProvision/create_entity_test.js#L239

const entity = {
      'id': 'urn:ngsi-ld:T:' + new Date().getTime(),
      'type': 'T',
      'AR1': {
        'type': 'Relationship',
        'object': ['urn:ngsi-ld:T:1234', 'urn:ngsi-ld:T:5678']
      }
    };

When listing subscriptions default MIME type should be `application/json`

Now default MIME type is application/ld+json (in the absence of an Accept header).

either `type` or `attrs` have to be present when querying /ngsi-ld/v1/entities

URI Expansion to its own file

Right now, URI Expansion is only used in orionldPostEntities.
The functions that implement the URI expansion are static functions "tailor made" for that specific request.
Soon other requests will need URI Expansion as well and the implementation will need to get more generic.

All query tests are failing

See

https://github.com/Fiware/NGSI-LD_Tests/blob/master/contextConsumption/query_entities_test.js

https://github.com/Fiware/NGSI-LD_Tests/blob/master/contextConsumption/query_entities_with_ld_context_test.js

Orion-LD crashes with the following payload

{
    "@context": [
        "http://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld",
        "https://raw.githubusercontent.com/GSMADeveloper/NGSI-LD-Entities/master/examples/Agri-Crop-context.jsonld"
    ],
    "id": "urn:ngsi-ld:AgriCrop:df72dc57-1eb9-42a3-88a9-8647ecc954b4",
    "type": "AgriCrop",
    
    "name": {
        "type": "Property",
        "value": "Wheat"
    },
    "alternateName": {
        "type": "Property",
        "value": "Triticum aestivum"
    },
    "description": {
        "type": "Property",
        "value": "Spring wheat"
    },
    "agriSoil": {
        "type": "Relationship",
        "object": [
            "urn:ngsi-ld:AgriSoil:00411b56-bd1b-4551-96e0-a6e7fde9c840",
            "urn:ngsi-ld:AgriSoil:e8a8389a-edf5-4345-8d2c-b98ac1ce8e2a"
        ]
    },
    "agriFertiliser": {
        "type": "Relationship",
        "object": [
            "urn:ngsi-ld:AgriFertiliser:1b0d6cf7-320c-4a2b-b2f1-4575ea850c73",
            "urn:ngsi-ld:AgriFertiliser:380973c8-4d3b-4723-a899-0c0c5cc63e7e"
        ]
    },
    "agriPest": {
        "type": "Relationship",
        "object": [
            "urn:ngsi-ld:AgriPest:1b0d6cf7-320c-4a2b-b2f1-4575ea850c73",
            "urn:ngsi-ld:AgriPest:380973c8-4d3b-4723-a899-0c0c5cc63e7e"
        ]
    },
    "plantingFrom": {
        "type": "Property",
        "value": [
            {
                "dateRange": "-09-28/-10-12",
                "description": "Best Season"
            },
            {
                "dateRange": "-10-11/-10-18",
                "description": "Season OK"
            }
        ]
    },
    "harvestingInterval": {
        "type": "Property",
        "value": [
            {
                "dateRange": "-03-21/-04-01",
                "description": "Best Season"
            },
            {
                "dateRange": "-04-02/-04-15",
                "description": "Season OK"
            }
        ]
    },
    "wateringFrequency": {
        "type": "Property",
        "value": "daily"
    }
}

Query secuence crashing OrionLD

Hi, and congratulations for the great work with OrionLD!

I've been testing the new broker and have found a really odd sequence that utterly crashes the broker. It even won't go back up after restarting the docker container.

The sequence is easy: with a mint new container (won't work with a previously existing container which has answered queries) launch two queries in sequence:

1. GET http://{{orion}}/ngsi-ld/ex/v1/version
2. POST http://{{orion}}/ngsi-ld/v1/entities with the following payload and headers:

{
    "@context": [
            "http://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld",
            "http://schema.lab.fiware.org/ld/jsonldcontext.jsonld"
        ],
    "id": "urn:ngsi-ld:Room:Room1",
    "type": "Room",
    "temperature": {
        "value": 23,
        "type": "Property",
        "unitCode": "C"
    },
    "pressure": {
        "value": 720,
        "type": "Property",
        "unitCode": "mm Hg"
    }
}

and for headers in the second query Content-Type: application/ld+json

Hope this mystery unveils something worth fixing back there ;)

Best regards,
Pedro.

observedAt is returned as number for this test

https://github.com/Fiware/NGSI-LD_Tests/blob/master/contextConsumption/retrieve_entity_test.js#L10

Double start bracket in HTTP Link header

The steps 06 and 07 in the functest ngsild_content_type_and_context.test shows that the HTTP Link header comes back with TWO initial start brackets:

Link: <<https://fiware.github.io/NGSI-LD_TestSuite/ldContext/testContext.jsonld>; rel=http://www.w3.org/ns/json-ld#context; type=application/ld+json>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"

Also, rel="http://www.w3.org/ns/json-ld#context" is there TWICE ...

Something is wrong here ...

JSON-LD Link header in GET requests is reported to be in error but actually it is not

Please check the input format at

https://github.com/Fiware/NGSI-LD_Tests/blob/master/contextConsumption/retrieve_entity_with_ldcontext_test.js#L102

When providing content which is not JSON nor JSON-LD HTTP status code shall be 415 and not 400

(spec has to be updated)

Error types should be only ETSI URIs

I have noticed that sometimes error payloads are generated as follows:

"type": "http://example.org/ngsi-ld/errors/ResourceNotFound" 

Error payloads "type" member shall always contain ETSI-defined URIs:

Error Type	HTTP status
http://uri.etsi.org/ngsi-ld/errors/InvalidRequest	400
http://uri.etsi.org/ngsi-ld/errors/BadRequestData	400
http://uri.etsi.org/ngsi-ld/errors/AlreadyExists	409
http://uri.etsi.org/ngsi-ld/errors/OperationNotSupported	422
http://uri.etsi.org/ngsi-ld/errors/ResourceNotFound	404
http://uri.etsi.org/ngsi-ld/errors/InternalError	500
http://uri.etsi.org/ngsi-ld/errors/TooComplexQuery	403
http://uri.etsi.org/ngsi-ld/errors/TooManyResults	403

Subscriptions GET and DELETE

Hi,
besides other problems with the NGSI-LD subscriptions (see #60 ) it seems there are some additional problems.
If I create a subscription
{ "id": "urn:ngsi-ld:Subscription:testsubscription", "type": "Subscription", "entities": [ { "type": "vehicle" } ], "notification": { "format": "keyValues", "endpoint": { "uri": "http://mycallback:8080/callback" } }, "@context": "https://fiware.github.io/NGSI-LD_TestSuite/ldContext/testFullContext.jsonld" }
I get a 201 Created back with location /ngsi-ld/v1/subscriptions/urn:ngsi-ld:Subscription:testsubscription. (So if I don't create it twice I get the right response without a crash.)
If I try to get all subscriptions I it seems the interface is not implemented yet:
{ "type": "http://uri.etsi.org/ngsi-ld/errors/BadRequestData", "title": "not implemented - GET /ngsi-ld/v1/subscriptions", "details": "no details" }
If I now want to avoid adding the subscription again I tried to delete it with
DELETE http://ourorion:1026/ngsi-ld/v1/subscriptions/urn:ngsi-ld:Subscription:testsubscription
This results in
{ "type": "http://uri.etsi.org/ngsi-ld/errors/BadRequestData", "title": "The requested subscription has not been found. Check id", "details": "urn:ngsi-ld:Subscription:testsubscription" }
This is strange as this is the same ID as used in the first step where I received the 201 Created.

subscription id shall be a URI

Test failing:

https://github.com/Fiware/NGSI-LD_Tests/blob/master/contextSubscription/create_subscription_errors_test.js#L24

When an attribute is not present a 404 error is raised incorrectly

Example:

GET /ngsi-ld/v1/entities/urn:ngsi-ld:Vehicle:V1234?attrs=nonPresentAttribute

Response is

{"body": {"details": "no details", "title": "No context element found", "type": "http://example.org/ngsi-ld/errors/ResourceNotFound"}, "headers": {"connection": "close", "content-length": "119", "content-type": "application/json", "date": "Thu, 22 Nov 2018 16:11:21 GMT"}, "request": {"headers": {"accept": "application/json"}, "method": "GET", "uri": {"auth": null, "hash": null, "host": "localhost:1030", "hostname": "localhost", "href": "http://localhost:1030/ngsi-ld/v1/entities/urn%3Angsi-ld%3AT%3A1542903081782?attrs=notFoundAttr", "path": "/ngsi-ld/v1/entities/urn%3Angsi-ld%3AT%3A1542903081782?attrs=notFoundAttr", "pathname": "/ngsi-ld/v1/entities/urn%3Angsi-ld%3AT%3A1542903081782", "port": "1030", "protocol": "http:", "query": "attrs=notFoundAttr", "search": "?attrs=notFoundAttr", "slashes": true}}, "statusCode": 404}

And it should be (as it is currently in Orion):

200 OK

{
"id": "urn:ngsi-ld:Vehicle:V1234",
"type": "Vehicle"
}

Crash in mongoQueryTypes functests

Something seems to have gone terribly wrong about mongo query types.
Many of the unit tests in mongoQueryTypes_test.cpp crash and I don't know why.
This is not the priority right now so I just disable the failing tests and continue.

See description of the crash in mongoQueryTypes_test.cpp, line 219:

FIXME: Test disabled as the call to mongoEntityTypes causes the unit test to crash, in the line:
...

To be revisited

Orion-LD crashes with this payload

POST /ngsi-ld/v1/entities/

{
    "id": "urn:ngsi-ld:ParkingSpot:santander:daoiz_velarde_1_5:3",
    "type": "ParkingSpot",
    "status": {
        "type": "Property",
        "value": "free",
        "observedAt": "2018-09-21T12:00:00Z"
    },
    "category": {
        "type": "Property",
        "value": [
            "onstreet"
        ]
    },
    "refParkingSite": {
        "type": "Relationship",
        "object": "urn:ngsi-ld:ParkingSite:santander:daoiz_velarde_1_5"
    },
    "name": {
        "type": "Property",
        "value": "A-13"
    },
    "location": {
        "type": "GeoProperty",
        "value": {
            "type": "Point",
            "coordinates": [
                -3.80356167695194,
                43.46296641666926
            ]
        }
    },
    "@context": [
        "https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld",
        "https://schema.lab.fiware.org/ld/context"
    ]
}

memleak of 215 bytes for functest 0000_ngsild/ngsild_entity_creation_parse_error_in_payload

The kjson library has a memleak for JSON buffers that present a JSON Parse Error.
It's a bit tricky, but MUST be fixed

Delete Entity returns HTTP status code 200 instead of 204

If Accept is absent "application/json" shall be assumed

Section 6.3.4 of the specification

Problem with timestamps and application/ld+json in notifications

Hi,
I think that it exists a problem with the timestamps in format ISO 8601 when receiving the notification data related to a subscription.
When I post an entity like the one in https://github.com/FIWARE/NGSI-LD_Experimental/blob/master/doc/example-code.md

curl http://localhost:1026/ngsi-ld/v1/entities/ -H 'Content-Type:application/ld+json' -iX  POST -d '{
   "id": "urn:ngsi-ld:Vehicle:A4568",
   "type": "Vehicle",   
   "brandName": {
      "type": "Property",   
      "value": "Mercedes"
    },
   "isParked": {
      "type": "Relationship",
      "object": "urn:ngsi-ld:OffStreetParking:Downtown1",
      "observedAt":"2018-12-04T12:00:00Z",
      "providedBy": {
            "type": "Relationship",
            "object": "urn:ngsi-ld:Person:Bob"
       }
    },
   "@context": ["http://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld"]
}'

I get the field observedAt correctly with a GET request:
curl "http://localhost:1026/ngsi-ld/v1/entities?type=Vehicle" -H "Accept: application/ld+json"

But when I create a subscription for getting that entity

curl http://localhost:1026/ngsi-ld/v1/subscriptions/ -H 'Content-Type:application/ld+json' -iX POST -d '{
 "id": "urn:ngsi-ld:Subscription:01",
 "type": "Subscription",
 "entities": [{"type": "Vehicle"}],
 "@context": "http://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld", 
 "description": "Notify me of all product vehicles changes", 
 "notification": {
     "format": "normalized",
     "endpoint": {
         "uri": "http://mydomain/",
         "accept": "application/ld+json"
       }
   }
 }'

I get the following response:

{
 "id":"urn:ngsi-ld:Notification:5ce59a3631178d6ca8eefbe6",
 "type":"Notification",
 "subscriptionId":"urn:ngsi-ld:Subscription:01",
 "notifiedAt":"2019-05-22T18:51:34Z",
 "data":[
     {
       "id":"urn:ngsi-ld:Vehicle:A4568",
       "type":"Vehicle",
       "brandName":{
            "type":"Property",
            "value":"Mercedes"
        },
       "isParked":{
            "type":"Relationship",
            "value":"urn:ngsi-ld:OffStreetParking:Downtown1",
            "observedAt":"",
            "providedBy":"urn:ngsi-ld:Person:Bob"
        }
     }
  ]
}

With content-type: application/json

As it can be seen, in my subscription I specify that I want my notifications to have content in ld+json format instead of json and the field observedAt is empty in the notification.
I am using docker-compose.

Furthermore, I was wondering if I could get in the notifications the creDate and modDate fields of the objects saved in Orion with a subscription.

Missing @context member in error responses

In some (all?) error responses, the @context member is missing in the payload.
See for example step 2+3 in functest ngsild_entity_creation.test

JSON-LD Link Header should not point to the Core @context

but to the Default @context or to the corresponding @context

@context specified by array gives an error

{
  "id": "urn:ngsi-ld:Vehicle:A4567",
  "type": "Vehicle",
  "brandName": {
    "type": "Property",
    "value": "Mercedes"
  },
  "isParked": {
    "type": "Relationship",
    "object": "urn:ngsi-ld:OffStreetParking:Downtown1",
    "observedAt": "2017-07-29T12:00:04Z",
    "providedBy": {
      "type": "Relationship",
      "object": "urn:ngsi-ld:Person:Bob"
    }
  },
  "@context": [
    "https://forge.etsi.org/gitlab/NGSI-LD/NGSI-LD/raw/master/coreContext/ngsi-ld-core-context.json",
    "http://example.org/cim/commonTerms.jsonld",
    "http://example.org/cim/vehicle.jsonld",
    "http://example.org/cim/parking.jsonld"
  ]
}

Support prefix expansion for URIs

We need to support cases

{
  "@context":  {
    "foaf": "http://xmlns.com/foaf/0.1/"
  },
  "id": "http://example.org/people#joebob",
  "type": "foaf:Person",
  "foaf:name":  {
     "type": "Property",
     "value": "Jose"
  }
}

JSON-LD Link Header format is wrong

It should be, for instance,

Link: <https://fiware.github.io/NGSI-LD_Tests/ldContext/testFullContext.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"'