Annotating nested structures/values in JSON-LD - json-ld

Say I have a JSON object with some properties in a nested object.
{
"title": "My Blog Post",
"meta": {
"publishedAt": "2016-08-01T00:00:00Z"
}
}
Is there an easy way I can just add a #context to my top-level object to reach
these properties (i.e. just "pass through" the meta object)? Something along
these lines:
{
"#context": {
"title": "schema:name",
"meta.publishedAt": {
"#type": "xsd:date",
"#id": "schema:datePublished"
}
},
"#id": "/my-article",
"title": "My Blog Post",
"meta": {
"publishedAt": "2016-08-01T00:00:00Z"
}
}
I would like to avoid having to add (duplicate) #id to the nested object, which is how I would otherwise have solved it:
{
"#context": {
"title": "schema:name",
"meta": { "#id": "_:meta", "#container": "#set" },
"publishedAt": {
"#type": "xsd:date",
"#id": "schema:datePublished"
}
},
"#id": "/my-article",
"title": "My Blog Post",
"meta": {
"#id": "/my-article",
"publishedAt": "2016-08-01T00:00:00Z"
}
}
This solution works, but requires duplication, and comes from ethanresnick's
comments on Github about annotating JSON API. He noted in another issue that #context is not "quite expressive enough to annotate the JSON API structure". I was hoping to prove him wrong at least with regards to this issue.

I just discovered that the latest JSON-LD spec includes a new section on nested properties. Defining your context like this should result in the desired output:
{
"#context": {
"title": "schema:name",
"meta": "#nest",
"publishedAt": {
"#type": "xsd:date",
"#id": "schema:datePublished",
"#nest": "meta"
}
},
...
}

If what you're trying to do is eat the meta element, then no, this can't be done in JSON-LD.
There have been discussions about doing an inverse-index that could do something like this, but I don't see an issue. You might create one at https://github.com/json-ld/json-ld.org/issues. At some point the CG, or a newly formed WG will start looking at feature requests for a new version.

Related

How do I compact and/or frame a json-ld document so that IRI values are expressed succinctly as well as keys?

Given an original JSON-LD document like this example, which defines the sources for some thing1:
[
{
"#id": "https://example.com/thing1",
"https://example.com/sources": [
{
"#id": "https://example.com/vocab/countries/EN"
},
{
"#id": "https://example.com/vocab/countries/FR"
}
]
}
]
(I'm simplifying quite a lot - in my real use-case this is larger and generated from RDF data. ex:vocab/countries is a SKOS ConceptScheme including EN and FR as Concepts)
I want to collapse it into something approximating what I'd use to express that in more normal JSON:
{
"#id": "https://example.com/thing1",
"sources": ["EN", "FR"]
}
I find I can use a context to collapse into name/values and shorten the names:
{
"#context": {
"#version": 1.1,
"ex": "https://example.com/",
"sources": {
"#id": "ex:sources",
"#type": "#id"
}
},
"#id": "ex:thing1",
"sources": [
"ex:vocab/countries/EN",
"ex:vocab/countries/FR"
]
}
An important element is "#type": "#id" which collapses the source definitions from (a list of) objects into key/value pairs, and the enclosing context term maps https://example.com/sources to sources.
But I cannot find a way which seems to do the same on the values, so that they become EN and FR instead of ex:vocab/countries/EN and ex:vocab/countries/FR. My experiments with adding #base and #vocab properties to the context don't appear to work like I expected them to.
I also need to do this in a scoped way, so that other properties besides sources can be defined which reference different vocabularies. For instance I might want to include languages, which could include terms from a vocabulary representing English, French, Gaelic, Breton, etc. In other words, I can't just set a global vocabulary or base for the entire document.
Can anyone tell me if this kind of transform is possible, and if so, how to achieve it?
JSON-LD Playground link here
You could set the expected values of sources to #vocab instead of #type and use a scoped context to set the #vocab to use. For example:
{
"#version": 1.1,
"ex": "https://example.com/",
"sources": {
"#id": "ex:sources",
"#type": "#vocab",
"#context": {
"#vocab": "https://example.com/vocab/countries/"
}
}
}
(playground link).
This says to treat the values of playground as vocabulary-relative IRIs, and sets the base of that vocabulary for those values. You should get the following:
{
"#context": {
"#version": 1.1,
"ex": "https://example.com/",
"sources": {
"#id": "ex:sources",
"#type": "#vocab",
"#context": {
"#vocab": "https://example.com/vocab/countries/"
}
}
},
"#id": "ex:thing1",
"sources": [
"EN",
"FR"
]
}

What JSON-LD structured data to use for a multi-pararaph, multi-image blogpost?

I have created the following JSON-LD for a blogpost in my blog:
{
"#context": "http://schema.org",
"#type": "BlogPosting",
"mainEntityOfPage": {
"#type": "WebPage",
"#id": "https://www.example.com"
},
"headline": "My Headline",
"articleBody": "blablabla",
"articleSection": "bla",
"description": "Article description",
"inLanguage": "en",
"image": "https://www.example.com/myimage.jpg",
"dateCreated": "2019-01-01T08:00:00+08:00",
"datePublished": "2019-01-01T08:00:00+08:00",
"dateModified": "2019-01-01T08:00:00+08:00",
"author": {
"#type": "Organization",
"name": "My Organization",
"logo": {
"#type": "ImageObject",
"url": "https://www.example.com/logo.jpg"
}
},
"publisher": {
"#type": "Organization",
"name": "Artina Luxury Villa",
"name": "My Organization",
"logo": {
"#type": "ImageObject",
"url": "https://www.example.com/mylogo.jpg"
}
}
}
Now, I have some blog posts that contain multiple paragraphs and each paragraph is accompanied by an image. Any ideas how can I depict such a structure with JSON-LD?
Background
I have created a simple blog which uses a JSON file for 2 purposes: (a) feed the blog with posts instead using a DB (by using XMLHttpRequest and JSON.parse) and (b) to add JSON-LD structured data to the code for SEO purposes.
When I read the JSON file I have to know which image belongs to which paragraph of the text in order to display it correctly.
Note: As you seem to need this only for internal purposes, and as there is typically no need to publically provide data about this kind of structure, I think it would be best not to provide public Schema.org data about it. So you could, for example, use it to build the page, and then remove it again (or whatever works for your case). Then it would also be possible to use a custom vocabulary (under your own domain) for this, if it better fits your needs.
You could use the hasPart property to add a WebPageElement for each paragraph+image block.
Each WebPageElement can have text and image (and, again, hasPart, if you need to nest them).
Note that JSON-LD arrays are unordered by default. You can use #list to make it ordered.
"hasPart": { "#list":
[
{
"#type": "WebPageElement",
"text": "plain text",
"image": "image-1.png"
},
{
"#type": "WebPageElement",
"text": "plain text",
"image": "image-2.png"
}
]
}
For the blog posting’s header/footer, you could use the more specific WPHeader/WPFooter instead of WebPageElement.

Best practice for large site

I am working on a large site and want to implement JSON-LD. The site has a large social media following and a lot of artist profiles and articles.
This is what I currently have, (the following code is from Google's guidelines)
Front page
<script type="application/ld+json">
{
"#context": "http://schema.org",
"#type": "Organization",
"name": "Organization name",
"url": "http://www.your-site.com",
"sameAs": [
"http://www.facebook.com/your-profile",
"http://instagram.com/yourProfile",
"http://www.linkedin.com/in/yourprofile",
"http://plus.google.com/your_profile"
]
}
</script>
Content pages
<script type='application/ld+json'>
{
"#context": "http://www.schema.org",
"#type": "WebSite",
"name": "About us",
"url": "http://www.your-site.com/about-us"
}
</script>
Profile pages of each artist:
<script type="application/ld+json">
{
"#context": "http://schema.org",
"#type": "NewsArticle",
"mainEntityOfPage": {
"#type": "WebPage",
"#id": "https://google.com/article"
},
"headline": "Article headline",
"image": [
"https://example.com/photos/1x1/photo.jpg",
"https://example.com/photos/4x3/photo.jpg",
"https://example.com/photos/16x9/photo.jpg"
],
"datePublished": "2015-02-05T08:00:00+08:00",
"dateModified": "2015-02-05T09:20:00+08:00",
"author": {
"#type": "Person",
"name": "John Doe"
},
"publisher": {
"#type": "Organization",
"name": "Google",
"logo": {
"#type": "ImageObject",
"url": "https://google.com/logo.jpg"
}
},
"description": "A most wonderful article"
}
</script>
Do I add one script tag per page or do I add all JSON-LD under one script tag? On the front page I have the "Organization" tag and show the social media links, do I add this on all pages?
You may have multiple script JSON-LD data blocks on a page, but using one script element makes it easier to connect the structured data entities: you can nest entities instead of having to reference their URIs.
What to connect? Your NewsArticle can
provide the WebPage¹ entity as value for the mainEntityOfPage property, and
provide the Organization entity as value for the publisher property.
This is only one possibility. Another one: You could provide the WebPage entity as top-level item and provide the NewsArticle entity as value for the mainEntity property.
If you have to duplicate data (for example, because the Organization is author and publisher, or because it’s the publisher of both, the WebPage and the NewsArticle), you can mix nesting and referencing. Give each entity an #id and wherever you provide this entity as value, also provide its #id.
¹ You are using WebSite, but you probably mean WebPage. Also note that the #context should be http://schema.org, not http://www.schema.org.

NoSQL Structure for handling labeled tags

Currently I have a hundreds of thousands of files like so:
{
"_id": "1234567890",
"type": "file",
"name": "Demo File",
"file_type": "application/pdf",
"size": "1400",
"timestamp": "1491421149",
"folder_id": "root"
}
Currently, I index all the names, and a client can search for files based on the name of the file. These files also have tags that need to be associated with the file but they also have specific labels.
An example would be:
{
"tags": [
{ "client": "john doe" },
{ "office": "virginia" },
{ "ssn": "1234" }
]
}
Is adding the tags array to my above file object the ideal solution if I want to be able to search thousands of files with a client of John Doe?
The only other solution I can think of is having something an object per tag and having an array of file ID's associated with each tag like so:
{
"_id": "11111111",
"type": "tag",
"label": "client",
"items": [
"1234567890",
"1222222222",
"1333333333"
]
}
With this being a LOT of objects I need to add tags to, I'd rather do it the most efficient way possible FIRST so I don't have to backtrack in the near future when I start running into issues.
Any guidance would be greatly appreciated.
Your original design, with a tags array, works well with Cloudant Search: https://console.ng.bluemix.net/docs/services/Cloudant/api/search.html#search.
With this approach you would define a single design document that will index any tag in the tags array. You do not have to create different views for different tags and you can use the Lucene syntax for queries: http://lucene.apache.org/core/4_3_0/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#Overview.
So, using your example, if you have a document that looks like this with tags:
{
"_id": "1234567890",
"type": "file",
"name": "Demo File",
"file_type": "application/pdf",
"size": "1400",
"timestamp": "1491421149",
"folder_id": "root",
"tags": [
{ "client": "john doe" },
{ "office": "virginia" },
{ "ssn": "1234" }
]
}
You can create a design document that indexes each tag like so:
{
"_id": "_design/searchFiles",
"views": {},
"language": "javascript",
"indexes": {
"byTag": {
"analyzer": "standard",
"index": "function (doc) {\n if (doc.type === \"file\" && doc.tags) {\n for (var i=0; i<doc.tags.length; i++) {\n for (var name in doc.tags[i]) {\n index(name, doc.tags[i][name]);\n }\n }\n }\n}"
}
}
}
The function looks like this:
function (doc) {
if (doc.type === "file" && doc.tags) {
for (var i=0; i<doc.tags.length; i++) {
for (var name in doc.tags[i]) {
index(name, doc.tags[i][name]);
}
}
}
}
Then you would search like this:
https://your_cloudant_account.cloudant.com/your_db/_design/searchFiles/_search/byTag
?q=client:jack+OR+office:virginia
&include_docs=true
The solution, that comes into my mind would be using map reduce functions.
To do that, you would add the tags to your original document:
{
"_id": "1234567890",
"type": "file",
"name": "Demo File",
"file_type": "application/pdf",
"size": "1400",
"timestamp": "1491421149",
"folder_id": "root",
"client": "john",
...
}
Afterwards, you can create a design document, that looks like this:
{
"_id": "_design/query",
"views": {
"byClient": {
"map": "function(doc) { if(doc.client) { emit(doc.client, doc._id) }}"
}
}
}
After the view is processed, you can open it with
GET /YOURDB/_design/query/_view/byClient?key="john"
By adding the query parameter include_docs=true, the whole document will be returned, instead of the id.
You can also write your tags into an tags attribute, but you have to update the map function to match the new design.
More information about views can be found here:
http://docs.couchdb.org/en/2.0.0/api/ddoc/views.html

How to use quick replies with attachment

In official documentation of quick replies says:
Quick Replies work with all message types including text message, image and template attachments.
But when i try send it with template_type: button, I got error:
{
"error": {
"message": "(#100) Only one of text or attachment can be specified",
"type": "OAuthException",
"code": 100,
"fbtrace_id": "H8w+ZfRbBub"
}
}
That I try to send:
{
"recipient": {"id": "234567890"},
"message": {
"text": "TEXT_MESSAGE",
"quick_replies": [
{
"content_type": "text",
"title": "SOME_TITLE_1",
"payload": "PAY_LOAD_1"
},
{
"content_type": "text",
"title": "SOME_TITLE_2",
"payload": "PAY_LOAD_2"
}
],
"attachment": {
"type": "template",
"payload": {
"template_type": "button",
"text": "TEXT_MESSAGE",
"buttons": [
{
"title": "READ_MORE_BUTTON",
"type": "postback",
"payload": "look:1:c"
}
]
}
}
}
}
when I sent without message.text, I got error:
{
"error": {
"message": "(#100) Cannot use both CTA and quick reply",
"type": "OAuthException",
"code": 100,
"fbtrace_id": "C0DDxGzaUUj"
}
}
What is CTA?
How send quick replies with attachment?
This message structure should work for sending an image attachment with quick replies:
{
"recipient": {
"id": recipient_id
},
"message": {
"attachment":{
"type":"image",
"payload":{
"url": image_url
}
},
"quick_replies": [
{
"content_type":"text",
"title": "Next Image",
"payload": "YOUR_DEFINED_PAYLOAD_FOR_NEXT_IMAGE"
}
]
}
}
Hope that helps dmitry.
try this way. It will insert both buttons and quick replies but button will be at top and quick replies will be at the bottom
"message":{
"quick_replies":[
{"content_type":"text",
"title":"title1",
"payload":"SUPPLEMENT_1"},
{"content_type":"text",
"title":"title2",
"payload":"PAYLOAD_1"
}
],
"attachment":{
"type":"template",
"payload":{
"template_type":"button",
"text":"your text",
"buttons":[
{
"type":"postback",
"title":"Confirm",
"payload":"USER_DEFINED_PAYLOAD"
}
]
}
}
}
So, I've got your same problem and I did some searches around.
What does CTA stands for?
First of all, CTA stands for Call-To-Action. These are the buttons you create with a request for a Button Template, Generic Template or with the Persistent Menu Thread Settings.
It seems that, although as you said FB official documentation explicitly states that Quick Replies are supported with ANY template, for some reason this doesn't include the Button template.
Why is that?
It seems logical to me that the Button Template should be used to present the user with a choice, same thing that the Quick Replies do, so it would be redundant.
Why is that not documented?
I'm assuming that it's probably due to the fact that the Messenger Platform API is still in beta and there are lots of changes from day to day. Personally, I'm working on a Java framework for doing Facebook Messenger bots and I'm finding that many things are not very well documented and often the error messages you get back are misleading. So, you should probably accept the fact that the Button Template and Quick Replies doesn't work together. Quick Replies works with any other template or with text messages though.
This worked for me while using dialogflow
{
"facebook": {
"attachment":{
"type":"template",
"payload":{
"template_type":"generic",
"elements":[
{
"title":"Welcome!",
"image_url":"https://petersfancybrownhats.com/company_image.png",
"subtitle":"We have the right hat for everyone.",
"default_action": {
"type": "web_url",
"url": "https://petersfancybrownhats.com/view?item=103",
"webview_height_ratio": "tall"
},
"buttons":[
{
"type":"web_url",
"url":"https://petersfancybrownhats.com",
"title":"View Website"
},{
"type":"postback",
"title":"Start Chatting",
"payload":"DEVELOPER_DEFINED_PAYLOAD"
}
]
}
]
}
},
"quick_replies":[
{
"content_type":"text",
"title":"Search",
"payload":"<POSTBACK_PAYLOAD>",
"image_url":"http://example.com/img/red.png"
},
{
"content_type":"location"
}
]
}
}

Resources