Can you list multiple features within the same Schema.org "LocationFeatureSpecification"? - schema.org

I am working on Schema.org Resort schema for a ton of resorts on a travel website and am trying to find the most efficient ways of filling out the schema with regards to amenities.
The current code looks something like this:
"amenityFeature": [
{
"#type":"http://schema.org/LocationFeatureSpecification",
"name":"Spa",
"value":"true"
},
{
"#type":"http://schema.org/LocationFeatureSpecification",
"name":"Internet Access",
"value":"true"
},
{
"#type":"http://schema.org/LocationFeatureSpecification",
"name":"Tennis Courts",
"value":"true"
}
]
My question is, can I write it like this instead to shorten lines of code:
{
"#type":"http://schema.org/LocationFeatureSpecification",
"name":[
"Spa", "Internet Access", "Tennis Courts"
],
"value":"true"
}
When I test it in Google’s Structured Data Testing Tool, it doesn’t give any errors. Here is what it looks like in the SDTT when I write it the short way:
And here is what it looks like if I do it the first/long way:
If I do it the short way, I want to make sure all those items are getting listed as amenities and not just different names for the same amenity. Otherwise, I'll go the long route.

No, each LocationFeatureSpecification represents one feature:
Specifies a location feature by providing a structured value representing a feature of an accommodation as a property-value pair of varying degrees of formality.
Your second snippet would represent one feature with multiple names.

Related

RESTapi nesting endpoint

Ok, new to RESTapi so not sure if I am using the correct terminology for what I want to ask so bear with me. I believe what I am asking about is nested resources in a service but I want to ask specifically about using it for separating a blob of "closely related" content. It may be easier to provide an example. Let's say I have the following service that could output the following:
/Policy
"data": [ {
"name": "PolicyName1",
"description": "",
"size": 25000,
.... (bunch of other fields)
"specialEnablement": true,
“specialEnablementOptions”: { <-- options below valid only if specialEnablement is true
“optionType”: “TypeII”,
“optionFlagA”: false,
“optionFlagB”: true,
“optionFlagC”: false,
...(bunch of other options here)
}
},
{ . . . }],
The specialEnablementOptions are only used if specialEnablement is 'true'. It is all part of this /Policy service so has no primary key other than the policy "name" (and doesnt make sense to have to generate one) so does not fall under some of the other questions I have been reading about nested resources.
It does make it more readable to separate this set of information since there are 12 or so options but, this is REST so, maybe human readability does not weigh heavily here.
I am being told that, if we do it this way, it makes it more complex to work with during POST/PUT/PATCH commands. Specifically, it is being said in my group that if we do this, we should require two calls....one that creates the policy main information then the user must call a second time to PATCH the specialEnablementOptions (assuming specialEnablement is true). This seems kludgy to me.
I am looking for expert advise on what the best practice is.
My questions:
Does having the specialEnablementOptions nested in this way cause a
lot of complexity. Seems to me that either way we have to verify
that the settings are valid?
Does having the specialEnablementOptions nested in this way require
two calls? In other words, can a user not do a POST/PATCH/PUT for
all the fields including those in the specialEnablementOptions in
one call? We are planning to provide a way for the user to do a
PATCH of just the specialEnablementOptions options without changing
any of the first level for ease of use but is there something that
prevents them from creating or modifying all settings in one call?
Another option is to just get rid of the nested
specialEnablementOptions and put everything at the same level. I
dont have a problem with this but wasn't sure if this was just being
lazy. I dont mind doing this if the consensus is it is the best way
to do it....but I also have a second example that is similar to this
scenario but is a bit more complex where putting everything under the parent level is not really optimal (I will show in the next example)
So, my second example is as follows:
/anotherPolicy
"data": [ {
"name": "APolicyName1",
"description": "",
"count": 123,
"lastModified": "2022-05-17-20.37.27.000000",
[{
"ownerId": 1
"ownerCount": 1818181
"specialFlags": 'ABA'
},
{ . . . }]
},
{ . . . }],
The above 'count' is the total number associated to that policy and then there is a nested resource by owner where the count by owner can be seen..plus maybe other information specific to that owner. The SUM(ownerCount) would equal "count" above it. Does this scenario change any of the answers to the questions above?
I appreciate your help. I found a ton of information and reference on when to use or not use nested endpoints but all the examples seem to orient around subjects that seem like they could easily be separated into two resource...for instance whether to nest /employees under /departments or /comments under /posts. Also, they didn't deal with the complexities of having nested endpoints vs avoiding them. And last, if using nesting is unnecessary as a readability standpoint.

What data source ID to use for Google Fit REST heart rate query?

I'm trying to retrieve aggregate daily heart rate summary data using the Google Fit REST API, but I'm struggling because either I'm missing something or the documentation seems to be very incomplete. I've successfully managed to retrieve aggregate daily step count by following one of the few available examples:
Request URL
https://www.googleapis.com/fitness/v1/users/me/dataset:aggregate
Request body
{
"aggregateBy": [{
"dataTypeName": "com.google.step_count.delta",
"dataSourceId": "derived:com.google.step_count.delta:com.google.android.gms:estimated_steps"
}],
"bucketByTime": { "durationMillis": 86400000 },
"startTimeMillis": 1438705622000,
"endTimeMillis": 1439310422000
}
I can't find any example for reading heart rate, so I'm trying to modify this for heart rate. I found this list of data types where it has this data type: com.google.heart_rate.summary but there isn't any information on what the dataSourceId should be. I tried just omitting it but I get this error:
no default datasource found for: com.google.heart_rate.summary
Does anybody know what I need to use for dataSourceId, or have a link to any decent documentation on data sources?
For resting heart rate, I use this:
"derived:com.google.heart_rate.bpm:com.google.android.gms:resting_heart_rate<-merge_heart_rate_bpm"
For heart rate or BPM, I use this:
"derived:com.google.heart_rate.bpm:com.google.android.gms:merge_heart_rate_bpm"
For completeness, I have included the datasources that I am using below for various readings:
DATA_SOURCE = {
"steps": "derived:com.google.step_count.delta:com.google.android.gms:merge_step_deltas",
"dist": "derived:com.google.distance.delta:com.google.android.gms:from_steps<-merge_step_deltas",
"bpm": "derived:com.google.heart_rate.bpm:com.google.android.gms:merge_heart_rate_bpm",
"rhr": "derived:com.google.heart_rate.bpm:com.google.android.gms:resting_heart_rate<-merge_heart_rate_bpm",
"sleep" : "derived:com.google.sleep.segment:com.google.android.gms:sleep_from_activity<-raw:com.google.activity.segment:com.heytap.wearable.health:stream_sleep",
"cal" : "derived:com.google.calories.expended:com.google.android.gms:from_activities",
"move": "derived:com.google.active_minutes:com.google.android.gms:from_steps<-estimated_steps",
"points" : "derived:com.google.heart_minutes:com.google.android.gms:merge_heart_minutes",
"weight" : "derived:com.google.weight:com.google.android.gms:merge_weight"
}
Depending on the datasource, sometimes it will provide an array of points. You can then choose to take sum, mean, median, etc of all points in the array accordingly.
You can list the data sources available for a given data type, for example :
Method
GET
Request URL
https://www.googleapis.com/fitness/v1/users/me/dataSources?dataTypeName=com.google.heart_rate.summary
Depending on what you're trying to achieve, you'll probably find a source either for com.google.heart_rate.summary or com.google.heart_rate.bpm to meet your needs, including merged sources.

Google DLP - Displaying the Region using InfoTypes.list()

After integrating the Google DLP API, the ListInfoTypes() currently returns the name, description, supported types of the infotypes present in the infotypes reference. Is it possible to also obtain the region for the infotypes like "Australia" or "Argentina" as a seperate field?
Currently this is my output:
"name": "AUSTRALIA_MEDICARE_NUMBER",
"displayName": "Australia medicare number",
"supportedBy": [
"INSPECT"
],
"description": "A 9-digit Australian Medicare account
I need the Region as well for example Region: "Australia" for every other infotypes.
I also got around to see locations.infoTypes.list() but I'm not sure which location I should enter in the filter to get any value.
Looking at the REST API there doesn't appear to be identifying data that can be formally used to determine the region. If we look at the InfoTypeDescription JSON structure found here:
https://cloud.google.com/dlp/docs/reference/rest/v2/ListInfoTypesResponse#InfoTypeDescription
we see that "name" is described as an "internal name of the InfoType". I wondered if we could depend on a structure of the string ... perhaps (.)*_.* as a regular expression grouping. While this might work, it shouldn't be relied upon without investigation of more samples and the docs don't describe the structure.
If you really need a solution, my recommendation would be to dump ALL the InfoTypes and then manually group the "name" fields into the regions of interest to you. You could then store this as CSV or JSON and have a reference piece of data that you could use in your app and regenerate as needed.
It's a great feature request I'll forward to the team. In the short term you can hack the name as ones that are regional will say they are in their name.

IBM Chatbot Assistant: Handling Multiple Entities

I have an entity called #spare_part and this entity has 4 values with the following example synonyms each:
both with synonyms filter, oil level indicator
not_defined with a synonym spare part
only_gear with synonyms valve, seal
whole_gear_box with a synonym complete set of gearbox
I want to be able to handle multiple entities given in the same input and address them later on, if needed. With this purpose I have coded the following in JSON editor:
{
"context": {
"sparepartrequest": "#spare_part.values"
},
"output": {
"generic": [
{
"values": [
{
"text": "You want an offer for the following parts: <?
$sparepartrequest.join(', ') ?>."
}
],
"response_type": "text",
"selection_policy": "sequential"
}
]
}
}
I have created a context variable called sparepartrequest as can be seen from the code lines above. For instance when the user says "I want an offer for a filter and a seal", the output of the bot is the following sentence:
You want an offer for the following parts: both, only_gear.
I don´t want the bot to prompt back the names of the values of the entity #spare_part, I rather want it to store the exact input of the user, for our case which would be filter and seal. So if the bot worked as I wanted it to, the output would look like the following:
You want an offer for the following parts: filter, valve.
Again, I believe that this can be handled with JSON Editor. Thank you !
Use two context variables. sparepartrequest as already done and sparepartrequest_literals as follows:
"sparepartrequest_literals":"<? entities['spare_part'].![literal].join(', ') ?>".
Then, in your text response call it by $sparepartrequest_literals to print the mentioned parts or use $sparepartrequest to refer to the detected values.

Google Analytics API - Sections returned in unwanted order

Using the GA API v4, I'm trying to retrieve data from multiple segments, that have been defined inside Google Analytics. My application does not know the names of these segments, but let's say they are called A, B, C and D inside GA. (Other users can rename the segments, so the names are really unpredictable.)
My application does have the ID's of these segments hardcoded. (Manually retrieved from https://developers.google.com/analytics/devguides/config/mgmt/v3/mgmtReference/management/segments/list.)
Now it's determined the list of data should be presented in some predefined order of significance. (That is, NOT in alphabetical order.)
So, I send a query to GA API with the segments array in the required order:
reportRequests["0"].segments[
{ segmentId: <id-for-segment-C> },
{ segmentId: <id-for-segment-B> },
{ segmentId: <id-for-segment-D> },
{ segmentId: <id-for-segment-A> }
]
To my surprise, the returned dataset is ordered in alphabetical order of segment name!
reports["0"].data.rows[
{ dimensions: [ "A" ], ... },
{ dimensions: [ "B" ], ... },
{ dimensions: [ "C" ], ... },
{ dimensions: [ "D" ], ... }
]
To make things worse:
The returned data does not include the segment ID's, I can only correlate these by making a separate API call to retrieve information for which segment name corresponds with which ID.
The alphabetic sorting is done with English rules, not with regional rules. (The segment names include the "Å" character, which according to Norwegian rules should be at the end of the alphabet, but is in the beginning for English sorting.)
Am I just imagining things? Am I causing problems by not completely understanding how the API works? Is this a bug in the API? Or is this actually by design?
1) Are you using the v3 or v4 versions? If v3, give a try to v4 and see if it helps. An alternative would be to use dynamicSegments (which I always use) instead of segmentIds: these could be stored in your DB, solving the segment ID-name resolution problem, and would also avoid GA maintenance issues (whereby users modify segments which then breaks your app).
2) Yes, they probably transliterate (Å -> A) and sort only after. I really wouldn't waste time investigating this, I doubt Google will ever change it (it's not a bad behaviour per se, APIs are designed to support coding, not subtleties of the human language, most people, especially Google Engineers based in US, wouldn't care :))