Re: could this json-ld be any simpler than this? (tips for a json-ld noob?)

Thanks Doug some follow up questions:

Hi there! Your JSON-LD does not follow the appropriate format.
>

Can you clarify what you mean?  My JSON-LD does process fine to N-quads in
the json-ld.org "playground", and I've successfully loaded those into
Virtuoso.
Doesn't that mean my "format" is witthin the bounds of what's considered
(technically speaking) "correct"?
Or are you saying I'm violating certain JSON-LD conventions?  (quite
possible I'm new :) )


> It also depends what you’re trying to accomplish with this schema.
>

So to clarify the JSON I showed is part of what's returned from a RESTful
service and is used for dropdowns in a UI that stores the "codes" in other
JSON documents into DynamoDB.
My goal is to wind up both with this data as well as the DynamoDB data (and
later data from other systems as well) as triples in Virtuoso for querying
with SPARQL.
So this is a microservices type of system with lots of RESTful calls
returning JSON and lots of code to ad hoc "join" the various JSON document
properties.
I'm really just playing with this stuff as an evaluation/POC for an
alternative architecture where Virtuoso replaces DynamoDB.
A lot of the JSON is replaced/enhanced into JSON-LD instead.
And ideally SPARQL queries replace a lot of the "ad hoc" code dealing with
the JSON today.
There's also other data sources e.g. spreadsheets and relational DBs that
could later be pulled in as RDF as well.
And then possibly down the road inferencing rules against this data may
prove very useful as well.

But my goal is not about putting this data on the web.
Standardized vocabularies and stuff I'm happy to use but it's not really a
central goal.
(plus I'm pretty green when it comes to OWL and RDFS if I'm honest it's
really just the basic understanding of RDF and SPARQL that I have).
So it's just a pragmatic goal of using standards-based RDF with (for now at
least) Virtuoso and SPARQL, over a more proprietary graph db like e.g.
neo4J.

And related:  I originally had "@type" properties in my JSON-LD, but when I
removed them and found the JSON-LD still processed fine...  I decided to
leave them out!
Is this maybe partly why you said it did not follow the appropriate
format?  Does that seem weird?  Do people view having the types as
fundamental to JSON-LD?
(I think part of the appeal of JSON is it's simplicity with it's minimal
typing)

Regarding these:

> Local Business: https://schema.org/LocalBusiness
>
> Restaurant: https://schema.org/FoodEstablishment
>
> Grocery Store: https://schema.org/GroceryStore
>
> A Product to Sell: https://schema.org/Product
>

I don't think any of these apply for my particular domain (which is more
about farming/agriculture stuff along with geolocation stuff).
Was there a reason you mentioned these specifically?

You can also see a created example of the product schema here:
> http://jsonld.com/product/
>

I did look at this thank you it's helpful.
Esp. noticed like this line:
"itemCondition": "http://schema.org/UsedCondition",

I notice on schema.org that's identified as an "Enumeration" that's really
what I was doing in my example - an "enumeration of crops".
So thanks maybe I should imitate that more.

For the languages, you can also use the Language type:
> https://schema.org/Language
>

I had seen Language but I hadn't seen how/where it would be used in my
example?
It felt like the "@language" thing was enough for me?  Would I change my
JSON-LD format somehow if I used "Language"?

>
>
> Google’s Structured Testing Data Tool is great to use to validate:
> https://search.google.com/structured-data/testing-tool
>

Thanks that does look really good I didn't know about it.
The docs for it look good too thanks.


> Hope this helps! Reply to me specifically if I can help any further.
>

Thanks again.

Darren