W3C home > Mailing lists > Public > public-linked-json@w3.org > October 2017

Re: JSON-LD and JSON-Schema linkage

From: TJ Koury <tjkoury@gmail.com>
Date: Tue, 24 Oct 2017 21:25:37 -0400
Message-ID: <CAC6QE-VQu_WGAiftZ_Ez-mMaaYnixrUyvM2CPVxzXvCHEftywg@mail.gmail.com>
To: Henry Andrews <henry@cloudflare.com>
Cc: Linked JSON <public-linked-json@w3.org>
Henry,

Thanks for the quick reply.  If you're looking for inputs, and I can submit
something formal if I'm not too off base here, I'd like to see something
along the lines of providing an schema property as a child of a context
node.

The goal would be the ability to make a one to many relationship with a
linked json being able to be associated with multiple schemas; in my case,
a NIEM entity instance being described for multiple persistence engines.

I'm of the opinion that using HTTP headers for schema references is not a
great option for several reasons, such as not being able to accurately
describe an HTML document with an embedded JSON-LD tag, and also forcing a
consumer to persist data pertaining to the  model outside of the standard.
In my specific use case, I'd like the schemas to be canonical when
referencing authoritative data sources, and not be an implemention detail
at time of data request.


On Oct 24, 2017 8:41 PM, "Henry Andrews" <henry@cloudflare.com> wrote:

Hi TJ,
  I'm currently the most active editor of the JSON Schema specification,
and this has been a recent topic of discussion for the forthcoming (no
later than Nov. 20th, barring unexpected problems) draft-07.

  I see you are using draft-04 for this.  In that draft (and up through
draft-06) the recommendations were:

* Use HTTP link headers if relevant:  "profile" as an identifier,
"describedBy" as a locator (most of the time they would be the same)
* Use "profile" as a media type parameter

However, per the author of the "profile" RFC this usage was never quite
right (JSON-LD use it correctly, though).  And application/json does not
support a profile media type parameter anyway.

  In draft-07, we are (probably) proposing replacing "profile" with a newly
proposed "schema" link relation type and/or media type parameter.  JSON-LD
could opt to support the media type parameter with application/ld+json, or
just use a "schema" link.  Whether this is correct, or sufficient, or if
there is a better approach, is something we really hope to get feedback on
with draft-07.  It is the main unresolved concern with the core spec, as
far as I know.  And I still find the "describedBy"-as-locator part a bit
odd, personally.

  If anyone wants to see a preview of draft-07, you can find it here:
http://json-schema.org/work-in-progress

thanks,
-henry


On Tue, Oct 24, 2017 at 3:55 PM, TJ Koury <tjkoury@gmail.com> wrote:

>
>
> ALCON,
>
> This has been asked before several times, but the answers always seem to
> get muddled down and lost in semantics (which is what we’re doing here, so
> I get it….).
>
> For reference:
>
> https://github.com/json-ld/json-ld.org/commit/019de59e296c39
> d7b5c0298d49d95b99fceb294a
>
> So there is a JSON-Schema document to validate ANY JSON-LD document
> against to make sure that it’s a valid JSON-LD document.  Awesome!
>
> Now, if I have a http://schema.org/Person, and an associated JSON-Schema
> document that defines the fields associated with Person, how do I add a URL
> to the associated JSON-LD document to reference that schema?
>
> My specific use case is to generate JSON-LD documents from NIEM instances,
> then create JSON-Schema documents for each persistence engine (database,
> file system, etc) that will store the instances, and embed within the
> JSON-Schema documents themselves the metadata required to create the
> tables.  Basically an Schema->SQL engine (another ORM!), but entirely based
> on the JSON-LD and JSON-Schema specs.
>
> -TJ
>
>
>
>


-- 

   -

   *Henry Andrews*  |  Systems Engineer
   henry@cloudflare.com
   <https://www.cloudflare.com/>

   1 888 99 FLARE  |  www.cloudflare.com
   -
Received on Wednesday, 25 October 2017 01:26:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:50 UTC