W3C home > Mailing lists > Public > public-lod@w3.org > January 2017

Re: making our HTML+RDFa queryable

From: Ruben Verborgh <Ruben.Verborgh@UGent.be>
Date: Tue, 24 Jan 2017 17:30:14 +0000
To: Kingsley Idehen <kidehen@openlinksw.com>
CC: "public-lod@w3.org" <public-lod@w3.org>
Message-ID: <BD5AAF6E-9B4D-4C47-8E45-FC49C108EF30@ugent.be>
> I don't understand your use of "we" I assume you mean this community? If so, why not? 

We = this community.
Why not = I don't have a big data crawl infrastructure in my basement :-)

>> But embracing that heterogeneity is hardest for consumers.
> Not really. 

So where are all the agents? [1]

> We just need more client tools, as exemplified by some of he stuff we at OpenLink Software (and you) and others are producing. 

Clients are the thing to invest in.

>> Heterogeneity goes against
>> “Be liberal in what you accept,
>> but conservative in what you publish”.
> Not in my understanding of heterogeneity, in a world were enforcing (or imposing) a single notation or document type isn't feasible. 

It's certainly not desirable indeed.
Don't get me wrong, I'm not advocating that
everybody should only use Schema.org andJSON-LD.
However, if we did, interoperability would be much better
(at the cost of diversity, which would be a bad thing).

This shows that heterogeneity and Postel's law are indeed in conflict;
but, like you, I see the solution in embracing that heterogeneity,
not in following Postel. Yet that comes with additional complexity.

> We need to please a variety of consumers rather than harvesters solely. 


> SPARQL queries combined with reasoning and inference can do wonderful things for data on a Semantic Web :) 

…but there are limits with regard to completeness and time
depending on the server-side interface (LD documents, SPARQL endpoint, …).
And currently, there are far less limits for harvesters
compared to individual consumers,
so this is why we should enable the latter group through tooling.



[1] http://www.cs.rpi.edu/~hendler/presentations/Hendler-IADIS.pdf
Received on Tuesday, 24 January 2017 17:30:49 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:30:19 UTC