RE: EasierRDF

Hi Hugh,

We use UUIDs, because of the long period in time and the many contributors of life-cycle information.
Next to the UUID we use rdfs:label for easy access. Label can change, the UUID stays lifelong.

Regards, Hans 

-----Original Message-----
From: Hugh Glaser <hugh@glasers.org> 
Sent: donderdag 17 februari 2022 12:41
To: Matthew Lange <matthew@ic-foods.org>
Cc: Semantic Web <semantic-web@w3.org>
Subject: Re: EasierRDF

Thanks Matthew.

This is somewhat off-topic - sorry.

Yes, working with any and all storage technologies is important.
A goodly while ago now, we built our Seme4 platform to enable just that.

It turns out that RDF documents are actually a great communication payload, irrespective of how things are actually stored and consumed.
And a Linked Data architecture manages the communication very effectively.
Where RDF is not possible, the payload can always fall back on anything the required systems can recognise, but LD is still a powerful architecture to manage things.

This enables Semantic Web application without ever storing RDF or ingesting into RDF stores.

A missing component in many systems that makes this way of doing things challenging, is the lack of proper identifier management, bridging between the sources.
There should be no expectation of static agreement on IDs/URIs, or even static alignment of IDs.
So our platform has a sameAs subsystem that is essentially a specialised KB of ID & URI equivalences for different purposes.
And all our platform components are “sameAs aware”, working with the equivalence sets of URIs indicated by whatever sameAs store is indicated, completely dynamically.

As I said, sorry, off the Easier RDF topic, but I felt prompted by Matthew’s post to write it, and I’ve tried to be brief :-)


> On 15 Feb 2022, at 21:42, Matthew Lange <matthew@ic-foods.org> wrote:
> 
> Thanks for looping me into the conversation Chris. 
> While it is true that folks who studied candles had no hope of creating lightbulbs--I am not sure the distinction between the (No)SQL and Semantic/Ontology technology stacks is quite so disparate. 
> 
> Indeed, at icicle.ai we are focussed on bridging semantic and "traditional" (json, (No-)SQL, etc) technology stacks in order to provide on and off ramps for application-developer communities. Our tagline is "Democratizing AI"--this really means meeting people where they are at in terms of their skill levels and tooling. So in addition to building semantically native tooling, some of the "bridging" questions we're asking include:
>  • How do we make it possible to easy to interrogate instantiated ontologies and then produce document/tabular assets that can be displayed/queried or otherwise computed over with more familiar application tooling?
>  • How do we make it possible to ingest familiar document/tabular data and facilitate semantic tagging so that these traditional data stores become semantically enabled?
>  • How do we make these tools, and their inclusion in varied (meta-) models, easier to use and "pluggable" in nature? 
> Don't get me wrong, training in new technologies is critical for workforce development--something I think a lot about. However, I believe this doesn't need to stymie development of bridging technologies and hybrid-data stacks that facilitate broader usage and exposure. 
> 
>

Received on Thursday, 17 February 2022 14:03:30 UTC