- From: Renaud Delbru <renaud.delbru@deri.org>
- Date: Wed, 20 Jun 2012 20:18:54 +0100
- To: Hugh Glaser <hg@ecs.soton.ac.uk>
- CC: Aidan Hogan <aidan.hogan@deri.org>, "<public-lod@w3.org>" <public-lod@w3.org>
There is also type properties (with a measure of their frequency extracted from Sindice dataset): http://www.w3.org/1999/02/22-rdf-syntax-ns#type (123,994,777) http://opengraphprotocol.org/schema/type (61,202,581) http://ogp.me/ns#type (17,184,227) http://opengraph.org/schema/type (2,443,773) http://purl.org/dc/elements/1.1/type (11,367,218) http://dbpedia.org/property/type (120,044) http://dbpedia.org/ontology/type (65,796) -- Renaud Delbru On 20/06/12 20:08, Hugh Glaser wrote: > Yes. > I think it is meant to happen at the consumer side. > The consumer initialises their store with appropriate equivalences and sub-thingies for their purposes. > If you are building an app that expects only one of these, then you aren't really building a Semantic Web app. > And ideally the app will extend the set as it finds equivalence stuff in the wild. > > By the way, we also have (at least) > rdfs.'comment', dbpedia.'abstract', dc.'description', dcterms.'description', core.'overview', jisc.'description', resex.'detailed-description' > when the system is trying to pick up something to show as a description of what I am looking at. > I realise I need to update the list :-) > I'll probably add your suggestions as well. > and I have been trying to work if I want fb: as well. > > Best > > On 20 Jun 2012, at 19:52, Aidan Hogan wrote: > >> On 20/06/2012 18:58, Barry Norton wrote: >>> Does the fact that Web users now need to mark up their pages with >>> *og:description*, *schema:description* /and/ *twitter:description* not >>> make anyone in those communities think that maybe /this/ one had a point >>> in the first place? >>> >>> And that maybe this proliferation is actually /harder /to manage than >>> dealing with (shock horror) multiple namespaces? >> >> Did someone say reasoning?! >> >> Cheers, >> Aidan >> >> P.S., >> http://vimeo.com/28667500 >> http://vimeo.com/28667555 >> >
Received on Wednesday, 20 June 2012 19:19:25 UTC