[deepamehta-users] json ld

Juergen Neumann j.neumann at junes.eu
Fri Mar 6 12:31:25 CET 2015


Hi Jörg,

good to read you share my notion that DM and JSON LD are fitting very
well. Maybe we could talk a bit more in detail about the possibilies by
phone or when meeting.

I see an incredible potential here, e.g.: DeepaMehta could be used in
any language, if all required objects exist inside Wikidata. :)

Lets talk!

Cheers,

Juergen



Am Donnerstag, den 05.03.2015, 02:48 +0100 schrieb Jörg Richter:
> Hi,
> 
> in the recent posting I focused on how JSON-LD support could be realized as a DM plugin and provided some info about DM's JSON format. Here I provide some thoughts about integrating JSON-LD support directly into the DM Core.
> 
> Indeed JSON-LD and DM have great affinity and DM is quasi ready for JSON-LD "by nature". In DM each type is identified by an URI already. The types delivered with the DM Standard Distribution could use URIs from public ontologies instead the DM-proprietary ones, that is e.g. "http://xmlns.com/foaf/0.1/givenName" instead of "dm4.contacts.first_name". From there it is quite straight-forward to have JSON-LD exported by the  DM Core directly.
> 
> 2 more considerations:
> 
> - The DM Core could provide both, the DM-specific JSON representation, and the JSON-LD representation of a DM Topic via the same URL by involving Content Negotiation. That is a certain topic is retrieved via this URL:
> 
> 	http://localhost:8080/core/topic/1234
> 
> What representation is returned would depend on the request's Accept header, that is
> 
> 	Accept: application/json		# get the DM-specific JSON representation (works already)
> 	Accept: application/ld+json		# get the JSON-LD representation
> 
> Even when it is the Core who accepts the request, the actual logic to create the JSON-LD representation could be factored out into a plugin (in order to keep the DM Core small). I just have to equip the Core with another extension point that would allow 3rd-party plugins to hook in and create the representations not handled by the Core itself.
> 
> - Unfortunately at the moment we're not free to choose arbitrary URIs for the types delivered with the DM Standard Distribution. That's because DM's workspace assignment policy is partly controlled by specific URI prefixes, e.g. DM automatically assigns all types whose URIs have the "dm4." prefix to the "DeepaMehta" workspace. However, the subject of JSON-LD and Type URIs arrives at the right moment as DM's workspace assignment policy is fiercely discussed just now (see https://trac.deepamehta.de/ticket/371). The question on JSON-LD definitely contributes to that discussion.
> 
> Cheers,
> Jörg
> 
> 
> On Mar 5, 2015, at 1:32, Jörg Richter wrote:
> 
> > Hi,
> > 
> > as I understood it a JSON-LD document is an arbitrary JSON document that is enriched by a "context" which basically maps the property names used in the JSON document to terms of known ontologies. This way a JSON document is connected to the RDF world and thus becomes part of the semantic web. What seems attractive about JSON-LD is its lightweight character that indeed makes it easy to make any JSON exporting application "semantic-savvy".
> > 
> > I would not integrate JSON-LD in the DM core in any way in order to keep the core format agnostic. On the other hand it would make perfect sense to build a "dm4-json-ld" plugin to deal with the JSON-LD features. Its service would basically offer:
> > 	1) emitting a JSON-LD context for any given DM type URI
> > 	2) let other plugins register mappings from their provided types to terms of known ontologies 
> > 	3) optional: exporting arbitrary DM objects to plain JSON
> > 
> > Point 3) means creating plain JSON like ...
> > 
> > 	{
> > 		"name": "Malcolm X",
> > 		"died": "1965-02-21"
> > 	}
> > 
> > ... instead relying on DM's rather verbose "meta" JSON (as exported by the DM Core service):
> > 
> > 	{
> > 		"id": 1234,
> > 		"uri": "...",
> > 		"type_uri": "dm4.contacts.person"
> > 		"value": "...",
> > 		"childs": {
> > 			"dm4.contacts.first_name": {
> > 				"id": 2345,
> > 				"uri": "...",
> > 				"type_uri": "dm4.contacts.first_name",
> > 				"value": "Malcolm X",
> > 				"childs": {}
> > 			},
> > 			"dm4.contacts.date_of_death": {
> > 				"id": 3456,
> > 				"uri": "...",
> > 				"type_uri": "dm4.contacts.date_of_death",
> > 				"value": "1965-02-21",
> > 				"childs": {}
> > 			}
> > 		}
> > 	}
> > 
> > Note: while in the former the properties ("name", "died") originate directly from the application domain, in the latter most of the properties ("id", "uri", "type_uri", "value", "childs") originate from DM's meta-model.
> > 
> > While not knowing enough about it I guess that a JSON-LD context resp. a RDF processor is not able to access the relevant parts from DMs meta JSON. That's why I guess point 3) is required.
> > 
> > Thank you, Jürgen, for pointing me to JSON-LD. Indeed their is a close affinity to DM, and DM could benefit from it. I would appreciate if somebody would be inclined to develop such a plugin, and offer any possible support.
> > 
> > Cheers,
> > Jörg
> 




More information about the users mailing list