- From: Nicholas Bollweg <nick.bollweg@gmail.com>
- Date: Sat, 03 Oct 2015 15:00:55 +0000
- To: Cory Casanave <cory-c@modeldriven.com>, "public-linked-json@w3.org" <public-linked-json@w3.org>
- Message-ID: <CACejjWzwiRZFsnUtqX1sJGxTKun7vj0cJ7cOEzBSuLfqXzahPg@mail.gmail.com>
Cory: I'm currently involved in some efforts using CAPEC, CVE, etc. standards, as well as SysML/UML XMI, to generate RDF/OWL/SPIN graphs of cyber-physical systems, attacks and defenses. I would definitely be interested, and maybe even qualified to provide some insight. Do you have some snippets you'd like to see represented? About publishing: As some other folk have pointed out for other efforts, if you are actually going to be publishing/exchanging data (i.e a library, standard, api), you would still want a canonical, versioned compaction context, which should produce documents that adhere to a JSON Schema... so there would likely still be a ton of work to do... but much of that is automatable. About modeling: The JSON-LD metamodel has proven really nice for the initial prototypes (mostly done in Jupyter Notebooks), and I'm pretty confident the solutions will scale (i.e. into a real graph stores of teratriples). The huge wins of consistent typographical/logical mechanisms for @id, @type and @context are tremendous, though I am really looking forward to non-janky inference (i.e. rdf:type/rdfs:subClassOf*) for inspecting types. Another upside is that there is no application-level parser/metametamodel needed at parsing time, as with XMI/MOF... several of the libraries (pyld, jsonld.js, etc.) provide a "link" method that can represent a document as an already dereferenced graph of native objects. About the prototyping process: here's a workflow snippet derived from my early work: http://nbviewer.ipython.org/gist/bollwyvl/31746ef40ccb697d4480 It's not as responsive as the json-ld playground... but you can actually query the results with sparql/slicing notation. You may note that I use YAML to actually author the content: I find this much more pleasing than JSON for hand-authoring... something that I'd love to see in the playground. Overall, I find the toolchain around building up JSON-LD and JSON Schema is far, far easier than XMI/XML in a non-native XML-type environment with extensive tooling, so it could be really good if your goal is easier integration. Certainly continue to engage the group, as I am hardly an expert in any of these topics, but let me know if you'd like to coordinate efforts! cheers nick On Fri, Oct 2, 2015 at 6:36 PM Cory Casanave <cory-c@modeldriven.com> wrote: > I am engaged with an Oasis standards group: > https://www.oasis-open.org/committees/cti/charter.php > > > > This group currently uses a rather large XML Schema but is considering > additional or replacement formats. Based on their requirements and interest > in JSON, I have suggested they look at JSON-LD. As a proof of concept we > will be rendering a few small examples in different formats/languages. > > > > My experience is with modeling (mostly UML) as well as RDF and OWL. While > we could prepare a LD example some help from an experienced practitioner > would be beneficial in making sure we use it as effectively as possible and > thus improve the possibility of it being used in the cyber community. This > is probably a few hours work. Please let me know if interested. > > > > Regards, > Cory Casanave >
Received on Saturday, 3 October 2015 15:01:32 UTC