Re: ANN: Griller - RDF from other places

Thank you David.

But please follow me a little with this train of thought. There is this
data, information, represented in particular ways of writing (I've lived in
Italy for 20 years, can still only speak basic English). The information,
or, post-LLM times, things we can see as embedded knowledge.  We have a lot
of tools with which to do it.
I was only repeating things like saying you can project this information
another way. Feels a bit 1999.

I'm not saying anything, the JSON-LD group had a much clearer idea of how
to do things.

But mate, I think this makes some sense.

The projection of *whatever* to a different model.

By way of web bits. Stick a URL in there, global. Relate to other things.

The mindmappy toys like Obsidian, you know as well as I do, local stuff is
good, but connecting to everything else might be better.

Back to the syntax point. Why not. We make a flying trivial note, in
markdown. Bit of (for heaven's sake) Python and it's connected to another
thought you had 10 years ago. Header has a URL for how it should be
interpreted, crude case title:this content:rest, information is on the web,
no..?

Cheers,
Danny.







On Sat, 10 Aug 2024 at 05:42, David Booth <david@dbooth.org> wrote:

> Nice simple idea.  I like how it standardizes what folks already do in
> an ad hoc way.
>
> Personally, I don't consider the special name to be a big issue, because
> any sane processor is not going to blindly run code from some random URL
> anyway.  So I don't see much danger in it being accidentally
> misinterpreted.  Think of it merely as a hint.
>
> Thanks,
> David Booth
>
>
> On 8/9/24 10:41, Danny Ayers wrote:
> > I've subjected this "ANN", but there's nothing written down yet. I'd
> > appreciate suggestions from behind other eyeballs.
> >
> > The proposal is to upcycle the notion contained in GRDDL [1], apply it
> > more widely, starting with JSON and markdown.
> >
> > For ref, below is an example from the GRDDL spec, but you need not look,
> > it boils down a really simple idea : in a particular document you
> > include 2 URLs. One declares there is a processing model that may be
> > applied to this; the other points to that specific process.
> >
> > GRDDL was motivated by the idea that it's pretty straightforward to
> > transform an XML doc, which is likely to be data-shaped, into an RDF
> > representation. It really is a neat way of doing it. Just two URLs, one
> > says "we have a mapping" the other says "this is the mapping".
> >
> > (I was in the Working Group, DanC didn't credit me, but the spec was
> > thoroughly ignored, hey ho)
> >
> > Implementation-wise, discussions didn't really get beyond what was
> > obvious at the time. You apply an XSLT stylesheet to the doc, you get
> > the RDF. With one stylesheet, swathes of docs are transparently RDF. Or
> > if you really want to do it manually, take the doc, get the XSLT, use
> > your XSLT engine of choice, out pops the RDF (I forget, we put down
> > RDF/XML? was probably pre-Turtle syntax, but irrelevant, conneg innit).
> >
> > But the mechanism can work elsewhere. I had to leg it from the JSON-LD
> > working group when it became clear the other folks knew what they were
> > talking about whereas I didn't.
> > But years later, I got the reductio :
> >
> > {
> >     data-view-transformation : "http://purl.org/stuff/griller.js
> > <http://purl.org/stuff/griller.js>"
> >
> >     stuff : { this: ["all", "the", "jsons"] }
> > }
> >
> > Yeah, I'm thinking just one URL, and put in a reserved name in whatever
> > the RFC for those is.
> >
> > A recipient takes the above, applies the script given by griller.js,
> > spits out whatever it's transformed into. (I'd incline towards
> > "text/turtle", but again, conneg).
> >
> > So there you have any JSON exposed in a syntax that can be interpreted
> > in the RDF model.
> >
> > But one thing I feel I need right now in my own project is the same for
> > markdown. So here we go :
> >
> > <!-- data-view-transformation : "http://purl.org/stuff/make-me-sing.js
> > <http://purl.org/stuff/make-me-sing.js>"-->
> >
> > Markdown processors typically pass through HTML, seems like a comment
> > will either be a verbatim comment, or non-existent in the output. Use it
> > or not, is very little extra load.
> >
> >   The plus side to this is that implementation can be really low cost,
> > the default being do nothing. The downside is that it calls for at least
> > one special name, something like "data-view-transformation" >
> > Cheers,
> > Danny.
> >
> >
> >
> >
> > <html xmlns="http://www.w3.org/1999/xhtml <http://www.w3.org/1999/xhtml
> >">
> >
> >    <head*profile="http://www.w3.org/2003/g/data-view
> > <http://www.w3.org/2003/g/data-view>"*>
> >      <title>Some Document</title>
> >
> >      <link*rel="transformation"*
> >         href="http://www.w3.org/2000/06/dc-extract/dc-extract.xsl  <
> http://www.w3.org/2000/06/dc-extract/dc-extract.xsl>" />
> >      <meta name="DC.Subject"
> >         content="ADAM; Simple Search; Index+; prototype" />
> >      ...
> >    </head>
> >    ...
> > </html>
> >
> >
> > [1] https://www.w3.org/TR/grddl/ <https://www.w3.org/TR/grddl/>
> >
> >
> >
> > --
> > ----
> >
> > https:// <http://hyperdata.it/danja>danny.ayers.name
> > <http://danny.ayers.name>
> >
>
>

-- 
----

https://hyperdata.it <http://hyperdata.it/danja>