💾 Archived View for gemi.dev › gemini-mailing-list › 000880.gmi captured on 2024-08-31 at 18:47:44. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hello All, I've written up a first draft of an RFC for using RDF within gemini resources to add parsable metadata and semantics. gemini://lonelysilo.ca/rfc/gemini-semantics.gmi I think it would be really cool if the feedback came in the form of a semantic comment resource from your own gemini capsule using an existing RDF schema (eg. https://schema.org/Comment ). Feedback is welcome in any form. Thank you
Are there any benefits from using RDF? It's kinda complicated and hard to understand.
On 23-Apr-2021 01:00, Chris McGee wrote: > I've written up a first draft of an RFC for using RDF within gemini resources to add parsable metadata and semantics. > > gemini://lonelysilo.ca/rfc/gemini-semantics.gmi <http://lonelysilo.ca/rfc/gemini-semantics.gmi> > > I think it would be really cool if the feedback came in the form of a semantic comment resource from your own gemini capsule using an existing RDF schema (eg. https://schema.org/Comment <https://schema.org/Comment> ). Feedback is welcome in any form. Hello Chris It was interesting to see your RFC for embedded RDF semantics in gemtext. I like to see new proposals of how people are adapting to Gemini to see what is possible and what can become naturalised within its orbit. Personally I don't have much of a horse in the semantic web race so take these comments with that in mind. However my impression is that it is not the success its originators hoped for, perhaps due to various reasons, including the effort and inherent ambiguities of classification, issues of trust and assurance of data encoding, lack of tool support for normal people to use etc. But maybe there is an active body of users who find there is a definite benefit? I don't object to finding additional interpretations of content on top of gemtext (after all that is what the gemini subscription adjacent spec captures, very successfully). However my main concern is that the semantics of the links are not what they normally are in gemini. For example the URL links are schema references, rather than browsable content for users. So the normal processes of reading a hypertext gemini document and following a link to another gemini document don't apply and so you have to approach such an encoded document with the expectation that many of the links may not be normal links. This is somewhat of a cognitive overhead. Gemtext at the moment is primarily technology for human clients, so I think any conventional usage has to work firstly for humans in mind, then perhaps also for other clients. My feeling would be perhaps a separate media type would be better to serve over the gemini protocol. Or even use one that already exists such as RDF/XML for those that want to experiment in this area. You could have such a file with the metadata easily linked from a gemini page as a "metadata" link. Also there were some discussions on the list a few months ago about metadata embedding in gemtext - I can't find the link right now but you should be able to find it in the email archives. regards - Luke
On Fri, Apr 23, 2021 at 09:22:47AM +0100, Luke Emmet <luke@marmaladefoo.com> wrote a message of 58 lines which said: > However my main concern is that the semantics of the links are not > what they normally are in gemini. For example the URL links are > schema references, rather than browsable content for users. So the > normal processes of reading a hypertext gemini document and > following a link to another gemini document don't apply and so you > have to approach such an encoded document with the expectation that > many of the links may not be normal links. This is somewhat of a > cognitive overhead. This specific issue could be solved by requiring that the URIs used as identifiers are URLs, and reachable and have content. This is a common requirment in the world of "linked data" and other semantic stuff <https://www.w3.org/TR/ld-glossary/#dereferenceable-uris> <https://explore.dublincore.net/competency_index/d2695955/s2696018/s2696061 /s2742457/s2742458/>. Let's quote the inventor of the Web <https://www.w3.org/DesignIssues/LinkedData.html>: "Use HTTP URIs so that people can look up those names." This is an old issue <https://lists.w3.org/Archives/Public/www-tag/2002Mar/0092>.
On 23-Apr-2021 09:41, Stephane Bortzmeyer wrote: > On Fri, Apr 23, 2021 at 09:22:47AM +0100, > Luke Emmet <luke@marmaladefoo.com> wrote > a message of 58 lines which said: > >> However my main concern is that the semantics of the links are not >> what they normally are in gemini. For example the URL links are >> schema references, rather than browsable content for users. So the >> normal processes of reading a hypertext gemini document and >> following a link to another gemini document don't apply and so you >> have to approach such an encoded document with the expectation that >> many of the links may not be normal links. This is somewhat of a >> cognitive overhead. > > This specific issue could be solved by requiring that the URIs used as > identifiers are URLs, and reachable and have content. This is a common > requirment in the world of "linked data" and other semantic stuff > <https://www.w3.org/TR/ld-glossary/#dereferenceable-uris> > <https://explore.dublincore.net/competency_index/d2695955/s2696018/s26960 61/s2742457/s2742458/>. > > Let's quote the inventor of the Web > <https://www.w3.org/DesignIssues/LinkedData.html>: "Use HTTP URIs so > that people can look up those names." > > This is an old issue > <https://lists.w3.org/Archives/Public/www-tag/2002Mar/0092>. > TBL has a positive balance on his authority credit score from inventing the web (in its early format!). But the semantic web/ontology movement has obviously struggled much harder to get out of the research community. Yes, dereferencability (is that a word?) is highly desirable attribute of URLs. I think what I was try to express that even beyond mere dereferencability, Gemtext should be primarily about linking to content a human would want to read - not just a technical schema reference into an ontology. Its about humans being the primary agents on the geminiverse and for us to build for them first and foremost. Hence my suggestion to use another (or derive a new) media type for extended metadata. But as I said, I don't really have a horse in this race. - Luke
Chris McGee writes:
> I've written up a first draft of an RFC for using RDF within gemini
> resources to add parsable metadata and semantics.
Thank you for putting in time and effort to the Geminiverse.
That said, I don't think the Semantic Web is a good fit for
Gemini, and the experience of the Semantic Web and linked data on the
WWW suggests that it is a technological dead-end that we are probably
better-off not pursuing.
This article does a good job of summarizing what the promise of the
Semantic Web was, and how it has come to be regarded as "as dead as last
year's roadkill":
https://twobithistory.org/2018/05/27/semantic-web.html
--
Jason McBrayer | “Strange is the night where black stars rise,
jmcbray@carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.”
| ― Robert W. Chambers,The King in Yellow
On Fri, Apr 23, 2021 at 10:07:31AM -0400, Jason McBrayer <jmcbray@carcosa.net> wrote a message of 24 lines which said: > This article does a good job of summarizing what the promise of the > Semantic Web was, and how it has come to be regarded as "as dead as last > year's roadkill": > > https://twobithistory.org/2018/05/27/semantic-web.html I agree with the general idea that the Semantic Web was a bad idea and is now dead but this article has also its own problems, ranging from the personal crusade of the author against XML (which is unrelated to the Semantic Web, which was always more abstract than a given data format) to frank mistakes like "To host your own website, you need to buy a domain name from ICANN".
The purpose of my RFC is to try to find specific feedback so that I can improve it. This is just a first draft and I hope to get early feedback, so I'm sure that it may not be in the best shape right now. If you find it complicated and hard to understand, I'd like to learn how to make that better, both in the way that I'm presenting the ideas and the specification itself. I think that there are a number of benefits to using RDF that I hope can enrich the Gemini space too. Adding semantic data to a resource both helps readers and computers to read specific detail out of a page or pages. An interesting example is wikipedia with those informative tables for certain topics of pages. Generally, you can go to a city and see not only nice flowing paragraphs about the place, but also focus on specific details, such as population, district and country. The authors for these pages have decided on some standards on what should go in those tables and the content evolves over time. While wikipedia is probably a very rigid example, I believe that semantics can be more organic and federated with discussions like we are having here. Semantic data doesn't have to be complicated and rigid. With RDF the schema doesn't need to be written first. Anyone can come up with a concept URI and then as its usage evolves someone can write up a formal schema description of it, if ever. There are of course benefits to standardization both to human readers and also computers. Popular RDF schemas are viewable using a web browser at the moment, but we can start writing our own using whatever URI we want, including Gemini, after some agreement on the syntax. At the simplest level RDF can be a kind of tagging mechanism. In my RFC at the beginning I just put a few triples in there that provide a type to the resource, a creative work. There's also a version number in case someone wants to cite a specific version of the RFC. It's marked as draft and my name is there for citation purposes. I could just leave the semantics at that and there's already some benefits to both human readers and computers. If we came up with a concept URI for our RFCs in gemini and GUS was indexing the types of resources then we might have a system for discovering everyone's RFCs out there. I was hinting in my original email about using the Comment type for feedback on the RFC. If we used this for feedback on RFC's and had support for that in one or more search engines then you can find comments out there about my RFC in gemini space itself and maybe even my own replies to those. This can be done without having to have a comment system built into my capsule or anyone's capsule. The discussion can be federated. Gemini won't need to have first-class interactivity built into the protocol and browsers, which I feel is one of many things that makes the web so terrible. Everyone just keeps publishing resources to their capsules as they do with this extra little bit of semantics. What I like about RDF is that we can just decide to do this and the decisions about the kinds of semantics that might be useful to all or subsets of us can evolve over time. Maybe some of us want to build entire ontologies between our capsules, shared, detailed vocabularies, while others are fine with just simple tagging mechanisms. Using some of what I've written in the spec we could document some of the schemas as gemini resources themselves. Meanwhile, there are some useful schemas out there, like on schema.org. Why not be pragmatic and use them when they make sense?. I'm assuming that since we are having this discussion over email that we don't believe that everything needs to be gemini resources and gemini protocol. I'm assuming that we all still have web browsers, some are using twitter, youtube, mastodon, etc. I would love for example to make use of schema.org's event types to post events, have people post their own replies to that event on their capsule and then use the computer to find out who is coming. Wouldn't that be an interesting way to have a federated option to facebook to be able to do that kind of thing without having to turn gemini into an interactive bloated mess that is the web? On the other hand, maybe that kind of lofty goal won't pan out, but at least the barrier to entry would be low for anyone willing to try. Maybe someone will find a much lighter weight set of RDF predicates? Or maybe this is just a bad idea that nobody will ever use it. Who knows, but with RDF these kinds of experiments are easy to try out and easy to evolve. I know that the details of RDF can get very complicated and the mapping to Gemini that I'm proposing is neither complete, nor perfect. I am trying to establish just a few extra conventions on top of the Gemini format and conventions I've seen already to achieve a reasonable fit between the two technologies and perhaps enrich both of them. For the remaining 20%, there are other RDF formats out there, such as Turtle and N-Triples, or XML (yuck) that can be hosted in a Gemini capsule, or a web server. Thanks all for the feedback so far. I'm happy for the engagement instead of just *crickets*. Chris On Fri, Apr 23, 2021 at 3:10 AM Anna “CyberTailor” <cyber@sysrq.in> wrote: > Are there any benefits from using RDF? It's kinda complicated and hard > to understand. >
It'd be nice if there were some proof of concept software to play with. First Gemini clients and servers emerged when the specification was far from final and they changed over time, so software (like GUS or Lupa fork) based on the draft RFC would be fine.
Hi Chris, I discovered your RFC a few days ago and I like it a lot. To provide an example I set up my capsule at marcel.flounder.online. It is indeed not easy to understand the full set of possibilities this extension offers. I tried to focus on a simple use case, which is a toy glossary for two concepts. For the concept gemini://marcel.flounder.online/Glossary/GeminiSpace I provide an example of linking into Wikidata. With this single link a vast amount of context from Wikipedia is added to the concept with minimal effort. Questions and comments welcome. Cheers, Marcel P.S. I am new to the Gemini space. Happy to have discovered this little pocket of the internet. Thanks for the great work you all did here.
---
Previous Thread: [announce] Spaceboy - Gemini server framework for Elixir
Next Thread: gmninkle splits up inklewriter JSON into a folder of linked Gemini documents