Comments (10)
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.
Related Issues (20)
- Idea: allow profiles to be requested on the new_post endpoint
- How to handle attachments with identical digests on a single post
- What Content-Type to return on the attachment endpoint
- Allow the attachment endpoint to redirect to a CDN location
- Why is the attachment endpoint needed?
- Relationship post type fragment
- Posts feed pagination issue
- Use of Cache-Control can be difficult in browsers HOT 2
- Allow a "types" parameter on the mentions endpoint
- Proposal: rename app.id to app.post
- Proposal: omit urls for not supported endpoints in meta post
- Provide a Status Update HOT 3
- Notification Status
- Will tor connectivity be enforced? HOT 3
- Definition of profile sturcture HOT 2
- Finish documentation HOT 2
- Meta posts' profile.website having a duplicate option or as an array. HOT 1
- Transaction post type HOT 1
- Community Issues: How to address the barrier to entry with prospective users? HOT 10
- tent is dead! What's the reason? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tent.io.