[HN Gopher] The Block Protocol
___________________________________________________________________
The Block Protocol
Author : jacobrussell
Score : 157 points
Date : 2022-01-27 17:32 UTC (5 hours ago)
(HTM) web link (blockprotocol.org)
(TXT) w3m dump (blockprotocol.org)
| catchmeifyoucan wrote:
| This kind of reminds me of https://adaptivecards.io/ from
| Microsoft.
| sambroner wrote:
| The Block Protocol is building on a pretty large history of
| similar ideas, but none have _really_ succeeded. Joel 's interest
| in this project is some cause for hope as is the embrace of
| existing standards like react, webcomponents, and HTML.
|
| Historically, OpenDoc is pretty relevant. So is OLE. More
| recently Notion, Coda, Microsoft Loop [1], Anytype.io, etc lean
| on the same concepts to allow you to break documents into
| independent & reassemble-able components. There hasn't been a
| large ecosystem here, although the componentized approach has
| more traction now as we move away from skeuomorphism.
|
| On the data side, Solid is the most relevant. The models are
| often the same, users give applications very granular data
| permissions and progressively authorize data access as required
| for additional functionality. Developers seem to dislike the
| model... You don't really know what you're going to be rendering
| and key features are not really used.
|
| From a pure schema perspective, you have schema.org. It's a
| pretty comprehensive attempt to catalog structured data for most
| use cases. It's nice that this project can kinda build on the
| semantic web, but most people ignore it! That being said,
| adoption would go a long way towards interoperability between OSS
| projects.
|
| I'd like to live in a world where everything works together? But
| I'm not so hopeful at this point because the ecosystem has very
| weird economics. Ultimately the "Block Developer" needs to be
| compensated, but the host is the one getting the SaaS or
| advertising payment. Obviously simple components can be free, but
| very complex ones may need micropayments, licensing fees, etc.
|
| [1] I helped start Fluid Framework, which is the underlying tech
| for Microsoft Loop. These are just my opinions and I no longer
| work for Microsoft.
| qwertyuiop_ wrote:
| "The Block Protocol is a global standard for building interactive
| blocks connected to structured data."
|
| is this a W3C standard ? why are they claiming its a global
| "standard" '
| notpachet wrote:
| I am torn on this. On the one hand I believe very strongly in the
| value that the semantic web can provide, and I applaud any effort
| to move us towards a future where we can more reliably interop
| between different applications on the web. I hope this pushes the
| needle in that direction.
|
| On the other hand, there is a very crowded graveyard of spiritual
| ancestors to this project, all of which were aspiring to similar
| goals. I am not seeing much direct acknowledgement here of why
| those other projects failed, or measures to prevent that from
| happening with the Block protocol.
|
| One common problem in semantic web projects, which Block doesn't
| seem immune to, is that the authors of those projects seem to get
| stuck thinking about how to model the presentational components
| on a given web page (lists, forms, images, calendar widgets)
| instead of the actual real-world stuff that these things
| represent (the books on my shelf, my allergies, a picture of my
| dog, my birthday). Don't get me wrong, richly-typed
| presentational components would be a big improvement. But I don't
| think they should be the end goal (unless perhaps you're in the
| blog-writing software business).
|
| Web pages are just one of many vehicles that we use for shuttling
| around information about the real world. We should try to come up
| with a system that is capable of representing real-world semantic
| information regardless of how that information ends up getting
| turned into pixels. It may be a web page, it may be Siri reading
| it to me, it may be AR.
|
| But when modeling real-world data, we always seem to walk into
| traps such as this (from the Block FAQ):
|
| > On other occasions you'll want to store information differently
| than how it's set out in the schema.org definition. For example,
| schema.org/Person defines a person as having a givenName and a
| familyName and yet in various cultures this isn't guaranteed.
| HASH uses preferredName and legalName instead - in communications
| and billing contexts respectively.
|
| How do we design a semantic typing system for real-world data
| that is amenable to the inevitable need to evolve or amend the
| schema, or leave off certain fields from a type instance, or tack
| on a few extra fields? Should our applications eschew canonical
| types (like schema.org's Person) in favor of a ducktyping
| approach (I don't care if you give me a schema.org Person, or a
| blockprotocol.org Person, or a notpachet.org Dog, as long as the
| blob has a numeric field for the "age" key?
| blobbers wrote:
| Is the idea that you build your website out of the blocks of
| other websites?
|
| As in TMZ and Techcrunch both publish something and you display
| their little blocks on your website? Is the data dynamic? It
| seems like there is data, and there is a block that can display
| said data.
|
| How is this any different from a view and a model(+controller?)?
| lootsauce wrote:
| Tried to sign up but can't get past the user name page.
| ciaranmn wrote:
| We had some teething issues earlier, apologies - if you try
| again now it should work.
| skybrian wrote:
| Back in the dot-com era we had "portal servers" which were
| basically a way to build a dashboard. This seems like a related
| idea? Put blocks in multiple columns and you have a dashboard.
|
| Maybe it will do better this time? But I feel like mobile phones
| went in the opposite direction with UI's designed for smaller
| screens, showing only one app at a time.
|
| We do have lots of documents and notebooks though. Maybe
| Observable's notebooks would benefit from something like this?
|
| Observable's notebooks let you define variables containing data
| and use them in other places, with live updates. It seems like
| you'd want something like that with blocks.
| lucasmullens wrote:
| So this seems to be a wrapper around web components, which might
| make web components easier to use in frameworks. By providing
| types, one could build a generator that takes a Block and creates
| a strongly-typed React/Vue/Svelte component, or even mobile
| components using a webview.
| danecjensen wrote:
| Can you elaborate on this? Why can't you make a generator for
| regular web components?
| yesimahuman wrote:
| Stencil has this feature btw: build a web component and it can
| output the strongly-typed React/Angular/Vue bindings to consume
| it natively in those frameworks.
| spankalee wrote:
| The Web Components Community Group is developing such a format
| to describe the types of components here:
| https://github.com/webcomponents/custom-elements-manifest
|
| People have already built tools that generate wrappers based on
| it.
| geektips wrote:
| Noob Question: How does this compares to an oEmbed.
| spankalee wrote:
| The security issue really should be front and center in a project
| like this. It's kind of disappointing to see it left as an
| exercise for the embedder.
|
| In the general case with untrusted 3rd party code the only really
| safe solution is to embed the blocks in cross-origin iframes. In
| the face of Spectre and Meltdown you really want those to be out-
| of-process iframes too, but that's up to the browser.
|
| iframes are cumbersome of course, so it would have been
| interesting to see the protocol focus on making them more
| seamlessly integrate with the embedding context with a standard
| postMessage protocol for things like securely forwarding content
| sizes (for auto-resizing the frame), events, and styling
| information across the frame boundary.
| DavidWilkinson wrote:
| This is a fair criticism of the public spec in its current form
| and we're working on documentation to help folks deal with
| this.
|
| We actively want to talk approaches through with more
| interested parties, and welcome contributions to the spec and
| docs.
|
| Sidebar -- for our part at HASH - we're optimistic about the
| role WebAssembly might play, having used it extensively in
| building the wider ecosystem of simulation tooling.
| miniatureape wrote:
| I think this is a really cool idea and something I have
| personally wanted (or at least thought I wanted) for a long time.
| In fact I wrote about a similar idea in 2013.[1]
|
| To me, this is just one part of something bigger though. I want
| to be able to store code in blocks and compose them into bigger
| blocks by chaining them and pipelining them. I'd also like
| versioning and some access rules.
|
| https://justindonato.com/notebook/urls-as-pointers.html
| bamazizi wrote:
| Interesting timing! After more than 3 years of preaching this
| idea to every ear I could find, no one listened! So I've been
| building a whole 'block oriented backend as a service' for a
| while now. Basically "bring your own frontend"
|
| Event driven, CQRS, with workflow orchestration of LEGO like
| microservices around block oriented data structures!
|
| Not an easy system to architect and build, but efforts like this
| are not only great validation or motivators but a great reference
| to compare and contrast!
| sambroner wrote:
| How would your approach be similar to or different than Edge DB
| [1]? Sounds like much more orchestration around the DB layer?
|
| [1] https://www.edgedb.com/blog/building-a-production-
| database-i...
| rapnie wrote:
| That is interesting. Is it open-source or intended to be?
| cxr wrote:
| Strong Xanadu vibes. Not surprising to see, since at least one of
| the people involved isn't new to trudging through the history of
| hypertext and has several Xanadu writeups. (See the backlinks on
| <https://maggieappleton.com/garden-history>.)
| usbfingers wrote:
| Many have tried - very recently - and seemingly stalled or failed
| at creating something like this with wide adoption, most notably
| Tim Berners-Lee with the SOLID protocol
|
| https://solidproject.org/
|
| https://solidproject.org/TR/protocol
|
| The roadblock is always getting major tech companies to accept it
| as a valid means of accessing user data.
|
| The amount of times I've heard about SOLID on NPR or other
| popular mainstream newscasts only to garner little to no support
| is astounding. Definitely take note where others have seemingly
| failed here because it's an uphill battle.
| tmikaeld wrote:
| Not the same thing, this "Block protocol" is for HTML widgets
| basically, re-usable HTML/CSS/JS components for sites/apps.
| usbfingers wrote:
| https://news.ycombinator.com/item?id=30105910
|
| At its heart, it is very similar.
|
| Comment above does a good job at describing the distinction.
| It's more than just re-usable HTML/CSS/JS, that's just how
| they're making it accessible to others. There are entities
| associated with the HTML/CSS/JS mapped alongside the
| component, which is the core benefit here.
|
| https://blockprotocol.org/spec for more info on how they're
| mapping data as entities
| sam_goody wrote:
| The real difference is the mindshare.
|
| joelonsoftware has bajillion readers, but he is much better
| known for founding stackoverflow.
|
| When SO endorses something, it will got a lot of mindshare, and
| becomes something that developers feel connected to.
|
| And with enough mindshare, the same project that would have
| been dead in the water becomes a given.
| usbfingers wrote:
| this is an excellent point
|
| Sort of tangent, but the fact that Block Protocol is also
| managing the distribution of the resulting UI components,
| unlike Solid which encouraged people to consume the data
| independently through an API, makes it more accessible.
| [deleted]
| anderspitman wrote:
| Personally my hesitancy in embracing Solid is the complexity.
| What I really want is essentially an HTTP filesystem API for my
| programs. Like a modern WebDAV to replace Google Drive. All the
| linked data stuff might be useful down the road but I currently
| don't need it.
| Ostrogodsky wrote:
| irq-1 wrote:
| To everyone that doesn't get it, think desktop UI controls, but
| for the web. Joel explains it clearly on the intro blog post:
| https://www.joelonsoftware.com/2022/01/27/making-the-web-bet...
|
| The strongly typed data is about not scraping the web; its typing
| for software reading the blocks and reusing the data.
| slyall wrote:
| Blog post from Joel Spolsky introducing this.
|
| https://www.joelonsoftware.com/2022/01/27/making-the-web-bet...
| pdonis wrote:
| This is, as others have commented, a much better explanation
| than the article at the top of this thread.
|
| But I'm not sure it's quite as simple as Joel makes it seem
| here:
|
| _> If you work on any kind of editor--be it a blogging tool, a
| note-taking app, a content management system, or anything like
| that--you should allow your users to embed blocks that conform
| to the Block Protocol. This way you can write the embedding
| code once and immediately make your editor able to embed a rich
| variety of block types with no extra work on your part._
|
| I don't see how this would work. Sure, the _data_ would be
| embeddable anywhere, but how does the editor know how to
| display it to the user and let the user interact with it? That
| 's not just "embedding code". And later on:
|
| _> Want to create a block that shows the Great Circle routing
| for a flight between two airports? Write the code for the block
| once and it can be embedded anywhere._
|
| Again, how does the application it's being embedded in know how
| to display it to the user? That seems like it requires more
| than just "embedding code". Each new kind of block requires
| each application to add code to _use_ the block.
|
| I agree the data exchange interoperability part is nice, but
| I'm not sure about the code reduction that seems to be implied
| here.
| open-source-ux wrote:
| Interesting idea but more questions than answers...
|
| The 'block' idea makes sense in the context of WordPress, but
| WordPress 'blocks' include layout blocks as well as content
| blocks.
|
| You could argue HTML is already a universal language that
| includes semantic 'blocks'. Is the block protocol a collection
| of HTML elements grouped together to form higher-level blocks?
|
| Will content 'blocks' be separated from style? What role will
| CSS component frameworks take in styling content blocks?
|
| We have embedded content from third-party parties already e.g.
| a tweet 'block', a YouTube video, an Instragram post, etc. The
| result is embedded 'blocks' stitched together to make a slow-
| loading page with a mess of HTML and CSS code (and a host of
| third-party cookies). How can the block protocol avoid this?
|
| As I said, interesting idea but many questions remaining at
| this early stage.
| jrochkind1 wrote:
| This explains it a lot better than the OP. (At first I was
| wondering if it had to do with "blockchain", because of the
| word "block" and the OP seeming like the kind of "solution in
| search of a problem" I associate with blockchain).
|
| But now I get it. Standardized content plugins across apps,
| basically?
|
| Sure, makes sense. I wish I thought any of the platforms
| involved were interested in making any investment at all in
| interoperability.
| DavidWilkinson wrote:
| Various are interested in making their platforms more
| extensible (the flip side of content interop).
| flutetornado wrote:
| I have always wanted Kindle to support a lot more features than
| what it does today. Digital books could be a lot more than what
| they are today. Want to embed a python REPL in a python book for
| users to test things right in the book, from a common source?
| Want to embed function graphs in a Math book from a common
| source? How about a theorem prover right there in the book? How
| about a Wolfram engine embedded in there to solve arbitrary
| calculus problems? How about a section in another book - license
| it from the other publisher and embed it into your book?
| Embedding a video, a web page, a 3D visualization engine, etc
| should all be possible in a digital book.
|
| Looks like this maybe able to achieve all of this. Just need to
| get Amazon Kindle team on board with this.
| gingkoguy wrote:
| Damn I thought square came out with something
| jawns wrote:
| The idea that you can create blocks that can easily be integrated
| into other applications presupposes that it's a desirable thing
| to have data that can be easily integrated into other
| applications.
|
| Which, for us as developers, seems like a given.
|
| But when you look at it through the lens of business users, that
| becomes a much more murky assumption.
|
| Look at RSS. Amazing way to aggregate content from other sources
| into a viewer that you have robust control over. Developers love
| it!
|
| But is RSS desirable from a business point of view? The landscape
| over the past 15 years suggests that no, it's not.
|
| Businesses would prefer to build walled gardens. They want
| complete control over the experience of consuming the content
| they produce, particularly when it comes to analytics and user
| data generated from that content. In many cases, their business
| model depends on it.
|
| While the Block site touts this protocol as a way to
| collaboratively build and share things within a community and
| ecosystem that runs on cooperative principles, that may be at
| odds with what our current business environment is incentivizing.
| CyberDildonics wrote:
| To be clear, you think that a standard data format and protocol
| is not worthwhile because some organizations don't release
| data?
| zozbot234 wrote:
| Standardized data formats and protocols exist already - see
| Linked Data and the Semantic Web. They're mostly used by non-
| commercial data providers _because_ of the aforementioned
| incentive problem.
| mejutoco wrote:
| I have been asked to implement RSS but private please, more
| than once :) One way to look at it could be that protocols
| create potential (sowing) and businesses exploit that potential
| (harvesting). Without the protocols I believe some of the
| walled gardens would also be impossible. The best example i can
| think of is email, which created opportunities for businesses
| for events, ecommerce, login systems, etc.
| culi wrote:
| Sounds like we need a different economic system that doesn't
| have these types of incentives
| AyyWS wrote:
| So you're saying block protocol would be a good fit for Red
| Star OS?
| doliveira wrote:
| I don't think there ever will be actual support from current
| major tech companies for such an endeavor, their business
| models are all about information and development lock-in,
| either explicitly or implicitly... I think it would have to
| start with academia and technical content, just like it did for
| the web (as I understand it)
| DavidWilkinson wrote:
| We've spent a lot of time thinking and talking to folks about
| the incentive structures around this, and think they stand on
| their own - although your skepticism was an initial worry we
| had, too. As it stands the Block Protocol enables embedding
| applications to make their products more useful to consumers.
| And block developers reach a wider audience with their tools
| than they would otherwise. There's a lot more to this that
| we'll write up nicely later.
| alexaholic wrote:
| oEmbed[1] meets Schema.org[2]?
|
| [1] https://www.oembed.com
|
| [2] https://schema.org
| tadfisher wrote:
| org-mode plugin when?
| metalliqaz wrote:
| The idea is cool, but why would any major service support this?
| The whole point of every startup these days is to grow to the
| point where they can hog all the users on to their own
| proprietary platform. Interoperability is anathema to the modern
| way of thinking.
| dataangel wrote:
| Sometimes software projects become a parody of the industry, this
| feels like one of those times. Abstraction astronauting to the
| 10th power, "A block is structured data" okay so like nearly
| ANYTHING? "You can send structured data between apps"... so it's
| JSON. "But also things like images!" ok, so files you've
| reinvented files. Maybe there is something actually useful here
| but Christ nobody is going to know based on this website.
| anderspitman wrote:
| Funny you invoke astronauting, given that AFAIK Joel Spolsky
| (involved in this project) coined or at least popularized the
| term:
|
| https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
| [deleted]
| slx26 wrote:
| >> Why would I want to build blocks with the Block Protocol?
|
| >> Blocks built with the Block Protocol can easily pass data
| between applications because the data within each block is
| structured.
|
| Yeah, what you said. What's their problem? What better world do
| they imagine? What's the approach taken on their solution? Very
| poorly explained.
|
| EDIT: Joel's article is much, much, much more convincing.
| atarian wrote:
| Ohh I get it. It's basically Docker/shipping containers for
| content.
| dgellow wrote:
| So, we now need to develop a kubernetes for content, right?!
| babyshake wrote:
| This has nothing to do with Jack Dorsey's Block, right?
| [deleted]
| spicybright wrote:
| It looks like it's not. I thought it was block chain just from
| the title myself.
| jrochkind1 wrote:
| When someone finally combines blockchain with semantic web,
| it'll be an immovable object meeting an unstoppable force and
| cyberspace will implode.
| MarkBennett wrote:
| ha ha, that was my first thought too
| egypturnash wrote:
| I feel like "You can move things from one to-do app to another
| to-do app!" is not really a compelling answer to the question
| "Why would I want to build blocks with the Block Protocol".
| cuteboy19 wrote:
| Relevant XKCD: https://xkcd.com/927/
| hackerlytest wrote:
| I knew what xkcd it was just by looking at the link. Lol
| mindcandy wrote:
| That's because people whip it out constantly and almost
| always where it's not appropriate. It's pretty rare that
| anyone tries to enact a new standard. So, instead we see
| this comic use to downplay every time that anyone does
| anything resembling anything that has ever been done
| before. Which is to say: to downplay everyone else's
| efforts. It has long gone past being funny to just being
| dismissive in it's widespread use.
| Dylan16807 wrote:
| Yeah, it seems like it shows up _any_ time a standard is
| suggested, which is taking a two sentence premise and
| ignoring 2 /3 of it.
| Ostrogodsky wrote:
| andjd wrote:
| Exactly this. There may not be a 'standard' that does any of
| this already, but the goal of this being portable across
| websites requires all of those websites to support this 'new'
| standard -- so there probably isn't a way this becomes wide
| spread enough to be useful.
|
| Relatedly, this follows the Notion model, where the UI is
| intrinsically tied to and limited by the data model. This may
| have appeal to developers who already are primed to think
| that way, but it's a terrible UI paradigm for everyone else.
| ohadron wrote:
| I came here for this comment
| Dylan16807 wrote:
| What are the existing standards?
| recursive wrote:
| http://microformats.org/
| pphysch wrote:
| HTML, JSON, iframes
| Dylan16807 wrote:
| The HTML and JSON standards don't get close to this by
| themselves.
|
| I don't think iframes really do it either, but even if
| they do nobody uses them that way and a replacement seems
| okay. It's not really a "competing standard" if nobody
| wanted to use it.
| pphysch wrote:
| If you look at https://blockprotocol.org/hub and can
| survive the <5fps (yikes!), you can see that they've
| demonstrated reimplementations of <p>, <img>, <h1> by
| piling mountains of Javascript/JSON on what is
| (hopefully?) just those standard HTML elements under the
| hood.
|
| If I have to pick between standard slow-moving HTML and
| wild west HTML-reimplemented-in-React, I will choose the
| former every time. I will never have to worry about "my
| <p> has been abandoned by its maintainer and is now
| malware!".
| ericflo wrote:
| Widgets are back!
| [deleted]
| divbzero wrote:
| How does the Block Protocol differ from or add to Web Components?
| Is it the standardization of how structured data that can be
| passed with the blocks?
| divbzero wrote:
| Based on what I can gather from the documentation I think the
| answer is basically: _Yes, it's the structured data._
|
| My initial confusion came from looking at Block Hub [1] which
| appears to be a collection of UI components. But the underlying
| Block Protocol specification [2] is all about structuring data
| around entity types and entity identifiers. Looking at a
| specific example of a block [3] the UI component is displayed
| next to the underlying data and schema.
|
| My guess is the creators of Block Protocol want to promote the
| free exchange of structured data and decided that coupling the
| data to UI components is the best way to do that? It's notable
| that the web has faced challenges encouraging use of both
| structured data (Semantic Web) and UI components (Web
| Components). Maybe they can be more appealing bundled together.
|
| I do hope the Block Protocol project tries as much as possible
| to reuse existing standards for data and components, building
| upon whatever we have that already works well.
|
| [1]: https://blockprotocol.org/hub
|
| [2]: https://blockprotocol.org/spec
|
| [3]: https://blockprotocol.org/@hash/image
| ciaranmn wrote:
| This is correct: it's the standardization of the interface
| between blocks and things using them, which includes
| structure in the data being passed back and forth, and the
| structure of the interface itself (e.g. what operations are
| available).
|
| We do want to promote the free exchange of structured data,
| and to have data captured and marked up according to some
| structure - we also want to promote the portability and easy-
| of-setup of UI components.
|
| Our FAQ illustrates how we relate to and intend to use
| existing standards - https://blockprotocol.org/docs/faq -
| we'd be interested in any others you think worth building on.
| spankalee wrote:
| If you want to promote portability, then blocks should be
| web components based, full stop. React-based blocks won't
| be usable without setting up React on the page.
|
| I think the FAQ around leaves a lot more open questions.
| Like:
|
| > but they do not standardize the interface between those
| blocks and the applications using them
|
| I'm not sure this is entirely true. Most reusable
| components these will have an interface described by a type
| system - this is how IDEs offer code completion and JSX and
| other template systems are type-checked.
|
| In the Web Components Community Group we're also
| standardizing a format for describing the entire interface
| of a web component, including its attributes, properties,
| events, methods, CSS variables and parts, etc. This is
| called the Custom Element Manifest:
| https://github.com/webcomponents/custom-elements-manifest
|
| Instead of being tied to json-ld, the manifest just
| documents what JS/TS type a property, etc., has. If a
| component has a person property that accepts a Person type,
| a tool can understand that.
|
| This manifest will give tools like catalogs, linters, and
| visual UI builders enough information to do high-level
| operations like generate demos, lint templates, assemble
| components without code, etc.
| euroderf wrote:
| So is there a sweet spot between microformats and Notion ?
| jitl wrote:
| (Disclosure: I work on Notion)
|
| This is a really cool idea!
|
| I think the challenging part of this project will be building
| intuitive and collaborative interfaces on top of the bare-bones
| data model. The challenge comes with two parts: (1) allowing
| blocks to compose, so I can nest a "task block" inside a
| "paragraph block", and (2) figuring out the collaboration model
| so multiple users can manipulate blocks at the same time, eg by
| typing characters. Both of these aspects are un(der)specified
| in the Block Protocol spec.
|
| For an example of a challenge building composable blocks,
| consider the suggested architecture - the project imagines
| different block types implemented as sandboxed iframes,
| orchestrated by some editor that stitches them together into a
| document or dashboard. This would make certain interactions
| difficult/impossible to implement in the browser. For example,
| you can't start a text selection in one iframe, and end the
| text selection in the next iframe. This means that each layer
| will need to implement many of the standard blocks, just to
| provide tools that operate on _the contents_ of more than one
| block at a time.
|
| I'm left wondering if there will ever be "block protocol
| native" apps, or if this will be more of an
| interoperability/import/export format between otherwise
| monolithic platforms that have their own much richer internal
| data format.
| DavidWilkinson wrote:
| (One of the BP maintainers here)
|
| If you'd be open to exploring this in the context of Notion
| we'd love to chat: david@hash.ai
| uoaei wrote:
| Oh look, someone reinvented semantic web again.
| redwall_hp wrote:
| But with an inherent dependency on an additional abstraction.
| Why a "block" when we already have a Document with many
| Elements that should have semantic meaning applied directly to
| them?
| iddan wrote:
| Exactly what I was thinking. The Semantic Web done the heavy
| lifting of defining general schemas (https://schema.org) and
| extending JSON (https://json-ld.org) and yet people don't
| subscribe to it. On the other hand, it has a lot of historical
| baggage (RDF, old schemas) that maybe a new standard can
| actually be better
| feanaro wrote:
| Why is RDF a bad thing?
| j-pb wrote:
| * Layers upon layers of complexity: Implementing CURIs
| alone is a non trivial task, although all that's really
| needed to describe entities and attributes is 128bit UUIDs.
|
| * There is no good build-in way for authentication and
| trust.
|
| * Description Logic (the foundation of OWL) has a
| fundamentally prescriptive philosophy, which makes it
| inappropriate for most practical applications.
|
| * No good library and tool support in general, due to the
| complexity.
|
| * Blank Nodes
|
| * No good consistency mechanism for distributed data
| generation, and Quads (having multiple graphs) don't
| properly solve this.
|
| * Using human readable entity and attr id's leads to more
| bike-shedding and accidental collisions than it's worth.
|
| * High barriers to entry.
|
| * After years of developer disappointment the earth is
| pretty much salted.
| jrochkind1 wrote:
| "CURIs"?
| j-pb wrote:
| A standard for shorter URI/URN identifiers:
| https://www.w3.org/TR/curie/
|
| It's needed because of the "readable resource name"
| criterion I also mentioned. Most of the complexity in RDF
| is actually not in the datamodel but leaks in from other
| parts of the web.
| contravariant wrote:
| As far as I'm concerned its most damning property is being
| all about relations but having no easy way to express
| properties of those relations.
|
| It's easy to express "<something> isa <cat>", but
| significantly harder to express "<something> isa <cat> with
| probability 98%". And all attempts to express the later
| just look like you're trying to build an impromptu
| relational database in order to fit an n-ary relationship.
| jcelerier wrote:
| I don't know how much that counts but every time I had to
| interact with RDF data I wanted to pull my eyeballs out of
| my sockets pretty much for the whole thing. Also, the idea
| that human knowledge can be categorized seems very
| laughable to me - I don't know of any RDF specification or
| ontology that holds in practice ; too many people have too
| many incompatible definitions for things and there is never
| one better than the others.
| k__ wrote:
| Maybe, finally a useable iteration of it.
| ciaranmn wrote:
| We want to fit into the existing semantic web tech rather than
| reinvent it - there's a FAQ here which hopefully helps to
| clarify: https://blockprotocol.org/docs/faq
| j-pb wrote:
| Kudos, this really feels like one of those ideas whose time
| has come. I'm tinkering on something very similar for longer
| than I care do admit, except I took on the daunting task of
| replacing RDF, and I'm sufficiently disillusioned by years of
| frontend work to base the UI off of TUIs and HyperCard.
|
| One thing that I experienced as a huge hurdle for semantic
| web technology is the lack of browser APIs to actually work
| with RDF/JSON-LD/Semantic Web data. There's really no
| complete and straightforward way to transfer, store and query
| semantic data in the fronted. JSON-LD works around this by
| exposing the graph as a tree regular old JS can work with,
| but that looses a lot of the flexibility and power of the
| original graph model, e.g. path independence and proper
| queries.
|
| I'll definitely keep an eye on how your ideas and solutions
| evolve!
| wrnr wrote:
| Well it does use RDF and probably has the same problem, was it
| `foaf:Person` or `schema:Person` or maybe even
| `ai:reificatedConceptNr1234`.
| anderspitman wrote:
| Interesting, especially since Joel Spolsky seems to be involved.
| Would like to see a comparison to microformats[0], RDFa, etc.
|
| [0]: https://microformats.org/wiki/Main_Page
| lelandbatey wrote:
| I've read and perused this, and I have some specific questions.
|
| 1. According to the spec[0], a "block package" is "a collection
| of files making a block type (which is 'a definition and
| implementation', the schema and the code) available for use by
| embedding applications, including its source code and
| accompanying metadata." However, when I browse to a
| "block"/"block package" in the Block Hub[1], I'm presented with a
| demo of the "block package" in the form of a concrete "block", a
| view of example data being provided to this "block", and a view
| of the schema of this "block". However, if this is meant to be a
| view of the "block package", shouldn't I also be able to find my
| way to the rest of this "block package", i.e. where do I view the
| implementation code? The spec says that a block package includes
| its source code, and the block hub seems to be a browser of block
| packages, but it doesn't give me the full view into said block
| packages. Is there a reason for this? Is it on the to-do list?
|
| 2. What's going on with the type signatures here? I see a lot of
| what look like type signatures, in both the spec and the schemas.
| In reading the spec, it seems like the type signatures are being
| used pretty loosely, maybe as pseudo code of a sort, as I don't
| see them being rigorously referred to. For example, I see that in
| "Specification > Block Types > Entity type functions"[2] under
| `createEntityTypes` it refers to accepting a type of
| "CreateEntityTypesAction" (no type signature), but then lower
| down it refers to accepting a type of
| "CreateEntityTypesAction<T>", but then says that the shape of
| that entity is just two hard-coded fields, with no reference to
| the generic type "T". What's going on here? Then if I view an
| actual block in the Block Hub[1], I see that the schema for that
| block also has definitions for entities with some kind of type
| signature 'something' going on e.g. "#/definitions/Record<string,
| {cellState:UseRowStateLocalState<{},unknown>;}>". Maybe those are
| for use with something like TypeScript? I'm not familiar with
| TypeScript, so I don't know how to parse those, though I do know
| that they're not specifying anything at the level of "JSON
| Schema"[3], so I assume they're related to either something in
| the spec or something in the implementation, or both. What's
| happening here? Are these types in the schema owned by the
| implementation (e.g. they're used by the source code of the
| implementation for JSX or something?), while the types in the
| spec are merely pseudocode?
|
| If there's already a pattern where additional layers of features
| such as typing/templating are being shoved into the schemas of
| Blocks, might this make interop between blocks more difficult in
| the future?
|
| [0] - https://blockprotocol.org/spec#terminology
|
| [1] - https://blockprotocol.org/@hash/table
|
| [2] - https://blockprotocol.org/spec/block-types#entity-functions
|
| [3] - https://json-schema.org/
| pjkundert wrote:
| Blocks of data and the semantic rules for their creation
| (validation), reading, updated and deletion (CRUD), with
| composability, versioning and robust APIs?
|
| That's a pretty succinct description of the Holochain project.
| Turns out that it is pretty powerful, once implemented. It isn't
| as simple as you might expect... :)
| DavidWilkinson wrote:
| Except it turns out that blocks and even block protocols were
| never actually blocked by the lack of a blockchain
___________________________________________________________________
(page generated 2022-01-27 23:00 UTC)