4 ms·
DISCLAIMER: Contains some self-promotion > Imagine hovering over a UI element and seeing who implemented it and when, what project it was part of, why the proj
by hobofan 4y ago
DISCLAIMER: Contains some self-promotion
> Imagine hovering over a UI element and seeing who implemented it and when, what project it was part of, why the project was initiated, and what kpis and goals it contributes to.
That's exactly what we are building at Field 33[0] with a package manager for ontologies (Plow[1]) as an underpinning to get a good level of flexibility/reusability/colaboration on all the concepts that go into your graph.
------
> Why isn’t semantic web more popular inside companies?
As part of building Field 33 we obviously also asked ourselves that question.
My rough hypothesis would be that ~10 years ago semantic tech didn't provide tangible enough benefits, and since then got left behind in the dust by non-semantic tech.
That caused a tech chasm that widened and widened, where the non-semantic side became a lot more accessible with quasi-standards (REST) and new methods of querying data for frontend usage (GraphQL), while the status quo of the semantic web space is still SPARQL (a query language full of footguns). Same thing goes for triple stores (the prevalent databases in the space) that roughly go through the same advancements as RDBMs, just at a much slower pace.
It also doesn't help that most work being done in the space comes from academia rather than companies that utilize it in production scenarios.
There is quite a nice curated list of problems/papercuts about the semantic web/RDF space[2].
Overall, despite the current status quo, I'm quite optimistic that the space can have a revival.
[0]: https://field33.com https://field33.com
[1]: https://plow.pm https://plow.pm
[2]: https://github.com/w3c/EasierRDF https://github.com/w3c/EasierRDF
- vaughan 4y agoInteresting work you guys are doing. I think a big reason for lack of popularity is familiarity of graphs in general. Most people wouldn't know of a good graph editor I would guess. Everyone knows documents and spreadsheets/tables/lists/folders, but it's rare to see a graph anywhere. Online and offline. If I have to think about an example of a graph in real-life what comes to mind is: a corkboard with strings going between them to track a criminal in a tv show, or a subway network map. In VSCode/IntelliJ, there is not one graph I look at frequently, even though pretty much all code is a data flow and dependency graph. I think part of this is that graphs always appear like a complicated mess, and we prefer hierarchies and categories. I would really like a tool like Airtable for graphs. You start with spreadsheets with columns relating to other columns, and then you view the graph next to it as you go. I don't know of a popular tool that does this. It's funny because behind-the-scenes of spreadsheets there is always big dependency graph that updates cells as changes come through. All the specs feel overly-complex too. Like a relic from the XML/SOAP days. For such a simple base concept (subject-predicate-object / entity-attribute-value) it feels like overkill. It's interesting though thinking about how JSON won, while being extremely inferior to XML. Although I think this ability to move fast has left us with a ton of untyped data lying around, and plenty of ad-hoc data transformations. I'm interested to read into the EasierRDF doc you sent - looks very interesting.
- hobofan 4y ago> You start with spreadsheets with columns relating to other columns, and then you view the graph next to it as you go. We are actually starting to crystalize something like that in our app. It's currently more read- than write-oriented but I think we are getting there. :) > It's funny because behind-the-scenes of spreadsheets there is always big dependency graph that updates cells as changes come through. Yup! Actually one dream that I have for our platform is that we'll build a Excel importer, that will import a fully fledged spreadsheet representation, including formulas that continue working (VBA macros excluded). Our platform does already support the core pieces required for this to work, there are just a ton of nitty gritty details to work out about how this would nicely integrate into the product in a way that isn't too cumbersome for our end-users. > All the specs feel overly-complex too. Like a relic from the XML/SOAP days. Oh, I could rant about that for days... RDF itself is already a bit weird in that aspect (the provide both the possibility to specify a datatype and a language tag, but not both at the same time to specify e.g. "German Markdown"). I don't think any comparable standard today would bake in localization on such a fundamental layer.