hi, | Link: rel="child", href="http://bla/bla" | | | Are you talking here about exposing the relationships only? | If you don't plan to include the resources in the result, | would be a list of links not enough? The source and the target of the relationship are also present in the data. This is how it works: send GET to /hawkular/inventory/.../relationships and you'll get all the relationships of the ... so for instance /hawkular/inventory/acme/prod/resources/host42/relationships will return all the relationships (and the basic info of the other side of this relationship, i.e. where host42 functions as a target and those where host42 acts as a source) I guess "Link: rel="child", href="http://bla/bla" is a good way how to address one resource from another one, but we need to expose the information about the relationship itself, it can have properties. | > Here is an example of 1 relation/edge: | > | > { | > "@context": { | > "inv": "http://hawkular.org/inventory/0.0.1", | > "baseUrl": "http://127.0.0.1:8080/hawkular/inventory/" | > }, | > "@id": "baseUrl:relationships/1337", | > "inv:shortId": "2", | > "@type": "inv:Relationship", | > "inv:source": { | > "@id": "baseUrl:tenants/acme", | > "@type": "inv:Tenant", | > "inv:shortId": "acme" | > }, | > "inv:label": "contains", | > "inv:target": { | > "@id": "baseUrl:acme/resourceTypes/URL", | > "@type": "inv:ResourceType", | > "inv:shortId": "URL" | > }, | | This doesn't really show me its strengths at the moment and looks | bloated. But perhaps the strength is that the relationship target | has its type supplied? in fact it could look like this and it'll be still json-ld: { "@context": "http://hawkular.org/inventory/0.0.1/relationship.jsonld", "@id": "baseUrl:relationships/1337", "shortId": "1337", "source": "baseUrl:tenants/acme", "label": "contains", "target": "baseUrl:acme/resourceTypes/URL" } It's up to us how much information we expose, almost everything can be remotely referenced. But I think the entity type is a good thing to have in the data. | Do we expect to use some existing clients to browse and visualize | our inventory using JSON-LD? it's one of the standards for storing the <subject,predicate,object> triples and it can be converted [1] to RDF, so yes, there are tools out there for visualizing the structure | The other question is if the query is 'give me all related entities to | this entity' | as you describe above, should we really "only" return the links? definitely, this can be tweak once we find out what we want from the UI perspective. There can be a path/query parameter that will embed the entities (with all the fields including the property hashmap) into the response instead of the link. | Or how | will we treat the fetching of the target entities? Can they optionally | be embedded in the answer? yes, json-ld supports embedding [2]. Currently, the source and target contain the name (shortId), type and the URL if we need to fetch more/less information. [1]: http://www.w3.org/TR/json-ld-api/#deserialize-json-ld-to-rdf-algorithm [2]: https://www.youtube.com/watch?v=UmvWk_TQ30A&t=3m05s

| Will it be possible to switch to plain JSON representation? Well, it's easy to do that, but I am not sure whether it is a good idea to have two serialization formats. It is a JSON, so it's easily consumable in JS