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

Re: making our HTML+RDFa queryable

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Tue, 24 Jan 2017 12:49:53 -0500
To: Ruben Verborgh <Ruben.Verborgh@UGent.be>
Cc: "public-lod@w3.org" <public-lod@w3.org>
Message-ID: <1f75778d-efb3-aca8-f2f7-ed40a6ca99bb@openlinksw.com>
On 1/24/17 12:30 PM, Ruben Verborgh wrote:
>> 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 :-)

You can cache data using browser hosted rdf stores, in the worst case.

Personally, I don't think mass crawling is the most useful Linked Data
exploitation pattern. Small Smart Data is where I see interesting stuff
happening on the client (consumer) side of things.

>
>>> But embracing that heterogeneity is hardest for consumers.
>> Not really. 
> So where are all the agents? [1]

There are many agents consuming RDF constructed using Schema.org terms.
Remember, <script/> and the structured data island mechanisms has lead
to an explosion of RDF using any combination of JSON-LD, Microdata,
RDFa, and even Turtle.

The Web Commons Data Report (referenced in my initial response)
demonstrates what's out there. We (OpenLink Software) have browser
extensions that work with this data. I am sure there are other doing
similar things too.

>
>> We just need more client tools, as exemplified by some of he stuff we at OpenLink Software (and you) and others are producing. 
> +1
> Clients are the thing to invest in.

Now that we have the publishing side of things sorted, yes.

>
>>> 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.

Neither am I .

> However, if we did, interoperability would be much better
> (at the cost of diversity, which would be a bad thing).

Heterogeneity is diversity, hence my peference for plurality on both sides.

>
> 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.

Yes, there is complexity, but that's part of the cost-benefit analysis
we have to make as solution developers and providers.

>
>> We need to please a variety of consumers rather than harvesters solely. 
> +1
>
>> 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.

hmmm..

Anyway, we agree on client tools. That's a good for now :)


Kingsley
>
> Best,
>
> Ruben
>
> [1] http://www.cs.rpi.edu/~hendler/presentations/Hendler-IADIS.pdf


-- 
Regards,

Kingsley Idehen	      
Founder & CEO 
OpenLink Software   (Home Page: http://www.openlinksw.com)

Weblogs (Blogs):
Legacy Blog: http://www.openlinksw.com/blog/~kidehen/
Blogspot Blog: http://kidehen.blogspot.com
Medium Blog: https://medium.com/@kidehen

Profile Pages:
Pinterest: https://www.pinterest.com/kidehen/
Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
Twitter: https://twitter.com/kidehen
Google+: https://plus.google.com/+KingsleyIdehen/about
LinkedIn: http://www.linkedin.com/in/kidehen

Web Identities (WebID):
Personal: http://kingsley.idehen.net/dataspace/person/kidehen#this
        : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this



Received on Tuesday, 24 January 2017 17:50:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:22:37 UTC