Consider partial or full alignment of data model to SIOC about tent.io HOT 10 CLOSED

Someday I hope the semantic web folks will decide to stop using in-band signaling.

from tent.io.

Hi sporkmonger, do you have alternatives to the sioc data model/vocabulary you would like to put forward? Note I am pushing common vocabulary here, and the use of uris asidentifiers

from tent.io.

The problem with RDF and its brethren isn't vocabulary or identifiers. It's where you put them. Both of those are effectively line noise to the uninitiated, and if you want ubiquity (you do), people need to be able to learn everything they need to know in ten minutes from a tutorial that a CS freshman could follow.

Move ontology out of the payload. Use a mapping from your vocabulary to your ontology. I'm biased of course, because this is the approach we took with all the post-GData APIs at Google, but two years in, I'm absolutely convinced that it's the right balance. If you're making a tiny API or protocol, it's quite possibly overkill, but as complexity increases, I'm more likely to recommend the approach, precisely because it keeps the complex bits out of sight and out of mind for anyone who doesn't need to worry about it.

In terms of rough details, you use JSON Schema to describe your data. If you need to map to an ontology, do it here. Then your payload can stay simple and easy for the copy-and-paste crowd to work with and you keep your parsing overhead low.

from tent.io.

Also you don't have to reinvent the wheel. You're welcome to any of the stuff we open sourced for our client libraries. It's all Apache 2.0. The Ruby client is particularly modular and I designed it explicitly with the goal of allowing the community to cannibalize it for parts.

from tent.io.

@sporkmonger This is a really interesting idea. Can you give me some links to the client as well as something that explains your JSON schema system?

from tent.io.

@titanous Sure.

Ruby Client:
https://github.com/google/google-api-ruby-client

Ruby dependencies of interest:
https://github.com/google/autoparse
https://github.com/google/signet

JSON Schema:
http://json-schema.org/

Google Discovery Service documentation:
https://developers.google.com/discovery/

Here's the rough context of how this all works in the Google example. Each API has a discovery document. For example, here's the discovery document for Google+. Your client library provides a way to download and interpret the discovery document, either at runtime or compile time, depending on the language and implementation. The Ruby client does this at run time, and provides you with an API reference object after parsing the discovery document. The API reference object tells the client what endpoints exist on the API. The way we did this isn't really a standard, but JSON Schema provides something vaguely similar in their concept of a "hyperschema", which I would probably recommend over the equivalent Google solution anyways. It also tells you what types of data you'll get back from a particular endpoint and what kind of data it accepts in any POST or PUT request. This is great because it allows you to do automatic data validation on the client, and because it allows you to provide a much more developer-friendly public interface to the data. And while JSON Schema didn't anticipate the usefulness of "out-of-band signaling" here, I don't see any reason why you couldn't incorporate identifiers and meta information that won't change on a per-payload basis.

None of this stuff is fully baked, so there's some pioneering to be done here, but I'm more than happy to point people in the right direction and make sure all of the relevant dependencies are solid if you start going down this path.

from tent.io.

Also, just to help decipher that discovery document, the two relevant fields for you would be schemas and resources. The schemas object contains a named mapping of all the schemas used by the API, while the resources object contains all the API endpoint descriptions (and provides links to the associated schemas used for request and response).

from tent.io.

So, just to be clear I am not asking for the underlying rdf model as much as I am suggesting to define a tent Post as semantically equivalent to a sioc Post. This can even be done in just the documentation.The primary benefit is that every other sioc producing site out there becomes trivial to map to and from.
Additionally, sioc as a vocabulary has been in the wild for some time, there may be terms from it that are useful to adopt.

The second part about uris as identifiers is an added benefit that may be worth investigating for a distributed environment like this.

My comments re json ld and rdf are simply meant to indicate the examples given in rdf xml are not the be all and end all - and that it is the vocabulary that is important.

from tent.io.

@CloCkWeRX That's fair. 👍

from tent.io.

We've started a repository of schemas at tent-schemas, feel free to move this discussion over there.

from tent.io.