Just wanted to share a couple links that might be of interest here for RDF
translation.
RDFLib is a Python library for working with RDF, a simple yet powerful
language for representing information.
https://github.com/RDFLib/rdflibJSON-LD parser and serializer plugins for RDFLib (Python 2.5+)
https://github.com/RDFLib/rdflib-jsonldHere is a online example of a RDF to multi-format translator.
http://rdf-translator.appspot.com/On Thu, Oct 1, 2015 at 1:39 PM, Cory Casanave <
cory-c@modeldriven.com>
wrote:
> Mark,
>
> Do I see it today? no. There may be some but I don’t know of it.
>
> Could it be used – sure. If you have very atomic data, like a sensor data,
> RDF can be VERY compact and understandable.
>
>
>
> Since I NEVER program to the data syntax (Libraries and MDA magic do that)
> I really don’t care if the data is in JSON or XML, but some do, and I could
> see a sensor hard coded like that. So the reason I am suggesting looking at
> the JSON/RDF (JSON-LD) format is that it reads better (and easier to parse)
> than the same thing encoded in XML while supporting the requirements I
> mentioned.
>
>
>
> I should have referenced the “standard” name: Json-ld
>
>
>
> Other note: I have no vested interest in RDF technologies, its something I
> use where it is the best choice.
>
>
>
> Here is some info on Wikipedia:
https://en.wikipedia.org/wiki/JSON-LD>
>
>
> Other note: I’m not entirely convinced a single “MTI” is a good idea, but
> if it is a distributed graph structure is the only thing that would scale
> from a sensor report to a query across millions of data points.
>
>
>
>
>
> *From:* Davidson II, Mark S [mailto:
mdavidson@mitre.org]
> *Sent:* Thursday, October 01, 2015 1:24 PM
> *To:* Cory Casanave; Wunder, John A.
> *Cc:* Jordan, Bret;
cti-stix@lists.oasis-open.org;
>
cti-users@lists.oasis-open.org> *Subject:* RE: [cti-users] MTI Binding
>
>
>
> Cory,
>
>
>
> I’m a little unfamiliar with RDF, so I have a clarifying question. In
> terms of RDF in JSON, is that something that you see security products
> using directly to interoperate? E.g., my SIEM uses TAXII + STIX/RDF/JSON to
> talk to my Sensor?
>
>
>
> Thank you.
>
> -Mark
>
>
>
> *From:*
cti-users@lists.oasis-open.org [
> mailto:
cti-users@lists.oasis-open.org <
cti-users@lists.oasis-open.org>] *On
> Behalf Of *Cory Casanave
> *Sent:* Thursday, October 01, 2015 11:09 AM
> *To:* Wunder, John A. <
jwunder@mitre.org>
> *Cc:* Jordan, Bret <
bret.jordan@bluecoat.com>;
>
cti-stix@lists.oasis-open.org;
cti-users@lists.oasis-open.org> *Subject:* RE: [cti-users] MTI Binding
>
>
>
> John,
>
> With respect to RDF in JSON, logical data models and other options, I will
> respond here but also look at updating the wiki. Sorry in advance for the
> long message – but I think it an important point.
>
>
>
> JSON has come from an environment of “server applications” supplying data
> to their “client applications”, where the client applications tended to be
> coupled and implemented in Javascript. The use has, of course, broadened,
> but that is the foundation and what it is very good at. What makes it
> “easy” is:
>
> · There is a well defined relationship between the client and
> server applications, usually under control of the same entity.
>
> · The server application is primarily in control of what the user
> will see through the client and how they interact.
>
> · There is a “dominate decomposition” of the data because it is
> serving a specific restricted set of use cases that the data structure and
> applications are tuned for. A strict data hierarchy works just fine. (Look
> up “dominate decomposition” – there is a lot of good information on the
> topic)
>
> · Data is coming from a single source and can be “bundled” for
> the next step in the applications workflow. Not much need to reference data
> from other sources or across interactions.
>
> · The semantics and restrictions of the data are understood
> within the small team(s) implementing this “client server” relationship –
> fancy schema or semantic representations are not needed.
>
> · The data source is the complete authority, at least for the
> client application.
>
> · Things don’t change much and when they do it is under a
> controlled revision on “both ends”.
>
> · The application technology is tuned to the data structure –
> Javascript directly reflects JSON.
>
> A good example may be the “weather channel” application on your phone and
> web browser. It is all managed by the weather channel developers (and
> perhaps their partners) for users (specific stakeholder group) to get
> weather information (specific information for a purpose) for a region (the
> dominate decomposition). I don’t know if they use JSON, but it would be a
> natural choice. This set of clients is served by servers designed for the
> above purpose.
>
>
>
> RDF & the “semantic web” stack has been designed with a very different set
> of assumptions:
>
> · Data providers and data consumers are independent and from
> different organizations, countries and communities.
>
> · Data providers and data consumers are independently managed.
>
> · Data providers have no idea what data consumers will use the
> data for, the consumer is more in control of what they consume and how they
> use it
>
> · There are numerous use cases, purposes and viewpoints being
> served – there is no dominate decomposition.
>
> · Data may come from multiple sources and the consumer may follow
> links to get more information, perhaps from the same or different sources.
> No static fixed “bundles” are practical.
>
> · Due to the distributed community the data semantics, relations
> and restrictions must be clearly communicated in a machine readable form.
>
> · Things change all the time and at different rates
>
> · No data source is complete, clients may use multiple sources
>
> · Any number of technology stacks will be used for both data
> providers and consumers.
>
> An example could be the position and path of all airliners, worldwide.
>
>
>
> This difference in design intent results in some specific differences in
> the technology:
>
> · RDF (and similar structures) are “data graphs” – information
> points to information without a dominate decomposition.
>
> · JSON is a strict hierarchy, essentially nested name/value pairs
>
> · RDF has as its core a type system with ways to describe those
> types
>
> · JSON has no type system, everything is a string. There is an
> assumption that “everyone knows what the tags mean”
>
> · RDF depends on URIs to reference data – this works within a
> “document” and across the web. This is where the “Linked data” term comes
> from (note: linked data may or may not be “open”)
>
> · JSON has no reference system at all, you can invent ways to
> encode references (locally or remote) in strings but they are ad-hoc and
> tend to be untyped
>
> · RDF is a data model with multiple syntax representations (XML,
> JSON, Turtle, etc)
>
> · JSON is a data syntax
>
> Here is the rub: Programming any application for a more general, more
> distributed, less “dominate”, less managed and less coupled environment is
> going to be harder than coding for the coupled, dominate managed and
> technology tuned one. Changing the syntax is not going to change that.
> Encoding the RDF model in JSON does allow a simpler syntax (than RDF-XML
> or, I think, current STIX) and does allow it to be consumed more easily in
> many clients, but the developer will still have to cope with references,
> distribution and “creating their viewpoint” in the application rather than
> having it handed to them. The flexibility has this cost and the community
> has to decide if and how to handle it.
>
>
>
> As I have suggested earlier, the best case is to make sure the description
> of your information (as understood by stakeholders) is represented in
> precise high-level machine readable models that will work with different
> decompositions and different syntaxes. It this is not the “singe source of
> the truth” for what your data means, you will be stuck in a technology –
> even if it is RDF.
>
>
>
> If there is going to be one “required” syntax it best be one that can
> reflect this general model well, serve diverse communities, support
> different technology stacks and is friendly to differing decompositions (no
> dominate decomposition). Of course, it then has to be as easy to understand
> and implement as is possible under these constraints.
>
>
>
> Where such general structures are encoded in XML it becomes complex. This
> is a combination of the need for the generality and the limits of XML
> schema. But, don’t blame XML for complexity that is inherent in the
> generality of CTI. The same complaint is levied on other general XML
> formats, like NIEM.
>
>
>
> RDF in JSON syntax provides the type system, reference system and allows
> for a structured composition but does not require it – it is more friendly
> to this general structure than XML Schema. This seems like a good option.
> It would be a very good option if generated from a high level model that
> would serve to bind all the technologies.
>
>
>
> Regards,
>
> Cory Casanave
>
>
>
>
>
> *From:* Wunder, John A. [mailto:
jwunder@mitre.org <
jwunder@mitre.org>]
> *Sent:* Thursday, October 01, 2015 9:18 AM
> *To:* Cory Casanave
> *Cc:* Jordan, Bret;
cti-stix@lists.oasis-open.org;
>
cti-users@lists.oasis-open.org> *Subject:* Re: [cti-users] MTI Binding
>
>
>
> Can you elaborate a little, Cory? What are the advantages of RDF in JSON
> vs. either native JSON, native XML, or RDF in XML? What are the
> disadvantages?
>
>
>
> If you could fill it out on the wiki that would be awesome, but if not
> then e-mail is fine too.
>
>
>
> John
>
>
>
>
https://github.com/STIXProject/schemas/wiki/MTI-Format-Analysis>
>
>
> On Sep 30, 2015, at 8:20 PM, Cory Casanave <
cory-c@modeldriven.com> wrote:
>
>
>
> What about RDF in JSON? This then has a well defined schema.
>
>
>
> *From:*
cti-users@lists.oasis-open.org [
> mailto:
cti-users@lists.oasis-open.org <
cti-users@lists.oasis-open.org>] *On
> Behalf Of *Jordan, Bret
> *Sent:* Wednesday, September 30, 2015 6:56 PM
> *To:*
cti-stix@lists.oasis-open.org;
cti-users@lists.oasis-open.org> *Subject:* [cti-users] MTI Binding
>
>
>
> From the comments so far on the github wiki [1], the consensus right now
> from the community is for JSON to be used as the MTI (mandatory to
> implement) binding for STIX. For those that agree or disagree or have a
> different opinion, please update at least the final Conclusions section
> with your opinion.
>
>
>
> [1]
https://github.com/STIXProject/schemas/wiki/MTI-Format-Analysis>
>
>
> Thanks,
>
>
>
> Bret
>
>
>
>
>
>
>
> *Bret Jordan CISSP*
>
> Director of Security Architecture and Standards | Office of the CTO
>
> Blue Coat Systems
>
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
>
> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that
> can not be unscrambled is an egg."
>
>
>
>
>