W3C home > Mailing lists > Public > public-vocabs@w3.org > April 2014

Re: Socialnetworks of a person or organization

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Fri, 11 Apr 2014 09:03:50 -0400
Message-ID: <5347E836.2060701@openlinksw.com>
To: W3C Web Schemas Task Force <public-vocabs@w3.org>
On 4/11/14 4:07 AM, martin.hepp@ebusiness-unibw.org wrote:
> I am perfectly fine with your broad notion of linked data;-)  With "all linked data stuff", I meant primarily abandoning the use of two separate slash-based URIs for the type and its page.

If you look at your paragraph above, you make reference to "type" and 
"page" . If the entities denoted by the literal identifiers "type" and 
"page" where the in fact the same, why would the paragraph above even be 
required? In a sense, its akin to saying: why bother with denotations 
like "Kingsley" and "Martin" when the HTTP URL that denotes a document 
(e.g., this post) will suffice when referring to either individual.

As I inferred in my posts (reflected in my glossary of terms), in the 
context of Schema.org, denotation granularity and scope is overkill. In 
short, I believe this is a problem that Schema.org has gone a long way 
to address i.e., providing a pragmatic bridge between Linked Data (which 
is useful) and Linked Open Data (which is also useful).  Proof of this 
utility is basically what I tried to showcase in my post about class 
equivalence oriented relations as a mechanism for bridging the masses of 
data produced via Schema.org and the masses of data in the Linked Open 
Data cloud [1].

[1] http://bit.ly/MyzbAh -- Class Equivalence based Inference & 
Reasoning demonstrated via Schema.org, FOAF, and GoodRelations.



Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

Received on Friday, 11 April 2014 13:04:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:39 UTC