Re: Drilling into the LOD Cloud
Hummm, sorry. When talking about classes it does make sense ;) Or even skos:concepts ( which we can declared to belong to a given vocab, for example ). ( have been working with instance data for too long ). This might call for a way to make statements about a specific IRI, but that would require tertiary relations or some syntactic convention... sounds like going the wrong way. But no worse than the inferencing complexity that would arise from discarding owl:sameAs as a simple conceptual bridge between vocabularies. Sounds like a prob indeed. Best, A On Mon, Sep 29, 2008 at 1:16 AM, Aldo Bucchi [EMAIL PROTECTED] wrote: I think you're overlooking something If you're using dc:author to state http://dbpedia.org/resource/R%C3%B6yksopp dc:author example:me ( which translates to: I *created Royksopp*, the music band ) And then Umbel states that *they created* the music band ( I made this up for the example ). http://umbel.org/umbel/ne/wikipedia/R%C3%B6yksopp dc:author ex:someoneElse . you will indeed run into problems when equating the two IDs. http://dbpedia.org/resource/R%C3%B6yksopp owl:sameAs http://umbel.org/umbel/ne/wikipedia/R%C3%B6yksopp But, AFAIK, this is *incorrect usage of dc:author* and not a design flaw re. owl:sameAs. Luckily, neither UMBEL nor DBpedia seem to be using dc:author incorrectly. Authorship metadata should not be attached to the ID for the concept, but to the vocabulary namespace or through other indirection. Which brings up another point: how do you state that a URI belongs to a given vocabulary. - URI opaqueness plays against here - is this really something we want/need? - ... If what you intend to equate is a document ( which usually have dc:* metadata ) with another doc that has different metadata, stop and rethink it. You might be wanting to equate the concepts they reference. A On Sun, Sep 28, 2008 at 6:30 PM, Damian Steer [EMAIL PROTECTED] wrote: On 28 Sep 2008, at 19:01, Kingsley Idehen wrote: Dan Brickley wrote: Kingsley Idehen wrote: Then between UMBEL and OpenCyc: 1. owl:sameAs 2. owl:equivalentClass If these thingies are owl:sameAs, then presumably they have same IP-related characteristics, owners, creation dates etc? Does that mean Cycorp owns UMBEL? Dan, No, it implies that in the UMBEL data space you have equivalence between Classes used to define UMBEL subject concepts (subject matter entities) and OpenCyc. I think Dan's point is that owl:sameAs is a very strong statement, as illustrated by the ownership question. If opencyc:Motorcyle owl:equivalentClass umbel:Motorcycle then they have the same extension. Informally, any use you make of one as a class can be replaced by the other without changing the meaning of the whole. However if the are owl:sameAs they name the same thing, so dc:creationDate, dc:creator, cc:license, rdfs:isDefinedBy etc etc are the same for each, which strike me as unhelpful side effects. owl:equivalentClass is the vocabulary mappers' friend :-) Damian -- Aldo Bucchi +56 9 7623 8653 skype:aldo.bucchi twitter:aldonline http://aldobucchi.com/ http://univrz.com/ -- Aldo Bucchi +56 9 7623 8653 skype:aldo.bucchi twitter:aldonline http://aldobucchi.com/ http://univrz.com/
Re: Drilling into the LOD Cloud
On 29 Sep 2008, at 00:51, Peter Ansell wrote: That is fine for classes, but how do you map individuals without metadata side-effects? The simple answer is you can't, at least in general. The trick with equivalentClass (and property) is that it takes equivalence with respect to a particular facet of the individual: its 'class-ness'. See also OWL 2 punning (as far as I understand it), where you'd think about [X qua class] and [X qua individual]. For a generic individual we have no facets. Now there's not necessarily a problem here. There are plenty of perfectly good uses for sameAs: foo:Tony_Blair owl:sameAs bar:Tony_Blair. But what about foo:Gordon_Brown owl:sameAs bar:PM_of_UK? foo:Geo_China owl:sameAs bar:PRC? There's a huge literature about these issues, which ought to be warning enough that there's no simple solution. And a neutral term equivalentTo strikes me as virtually useless. So go for the easy patches, things like sameConceptAs and the frbr-ish sameWorkAs. They cover a lot of what we want to do. I could see sameGeoRegion having some utility in the future, and no doubt others can chip in more. These are my Monday morning thoughts, so be warned. Damian
Re: Drilling into the LOD Cloud
On 29 Sep 2008, at 05:16, Aldo Bucchi wrote: I think you're overlooking something If you're using dc:author to state http://dbpedia.org/resource/R%C3%B6yksopp dc:author example:me ( which translates to: I *created Royksopp*, the music band ) And then Umbel states that *they created* the music band ( I made this up for the example ). http://umbel.org/umbel/ne/wikipedia/R%C3%B6yksopp dc:author ex:someoneElse . you will indeed run into problems when equating the two IDs. http://dbpedia.org/resource/R%C3%B6yksopp owl:sameAs http://umbel.org/umbel/ne/wikipedia/R%C3%B6yksopp But, AFAIK, this is *incorrect usage of dc:author* and not a design flaw re. owl:sameAs. Yes, this is incorrect usage of the property. (I presume you mean dc:creator.) Luckily, neither UMBEL nor DBpedia seem to be using dc:author incorrectly. Authorship metadata should not be attached to the ID for the concept, but to the vocabulary namespace or through other indirection. What we usually do: We attach the metadata to the *document* that contains the *description* of the entity. So, in the DBpedia case the authorship information would be attached to the URI of the RDF document describing the band: http://dbpedia.org/data/R%C3%B6yksopp and not to the band's identifier. Multiple datasets can of course talk about the same band, but they will do so in different documents, and the different documents will have different metadata. This is the Named Graph model of metadata management. It works very well with Linked Data, but it's less clear how to apply it best to SPARQL-accessible RDF data. Which brings up another point: how do you state that a URI belongs to a given vocabulary. I'm not convinced that this is a useful thing to do. When defining RDFS/OWL terms, you can use rdfs:isDefinedBy to connect the class/ property to the defining RDFS/OWL document. - URI opaqueness plays against here - is this really something we want/need? - ... If what you intend to equate is a document ( which usually have dc:* metadata ) with another doc that has different metadata, stop and rethink it. You might be wanting to equate the concepts they reference. Yes exactly, nicely put. Yours, Richard A On Sun, Sep 28, 2008 at 6:30 PM, Damian Steer [EMAIL PROTECTED] wrote: On 28 Sep 2008, at 19:01, Kingsley Idehen wrote: Dan Brickley wrote: Kingsley Idehen wrote: Then between UMBEL and OpenCyc: 1. owl:sameAs 2. owl:equivalentClass If these thingies are owl:sameAs, then presumably they have same IP-related characteristics, owners, creation dates etc? Does that mean Cycorp owns UMBEL? Dan, No, it implies that in the UMBEL data space you have equivalence between Classes used to define UMBEL subject concepts (subject matter entities) and OpenCyc. I think Dan's point is that owl:sameAs is a very strong statement, as illustrated by the ownership question. If opencyc:Motorcyle owl:equivalentClass umbel:Motorcycle then they have the same extension. Informally, any use you make of one as a class can be replaced by the other without changing the meaning of the whole. However if the are owl:sameAs they name the same thing, so dc:creationDate, dc:creator, cc:license, rdfs:isDefinedBy etc etc are the same for each, which strike me as unhelpful side effects. owl:equivalentClass is the vocabulary mappers' friend :-) Damian -- Aldo Bucchi +56 9 7623 8653 skype:aldo.bucchi twitter:aldonline http://aldobucchi.com/ http://univrz.com/
Re: Drilling into the LOD Cloud
Hi all, First of all, I think that this thread is going out of control and some things have to be keep into mind when we talk about this stuff. Then between UMBEL and OpenCyc: 1. owl:sameAs 2. owl:equivalentClass If these thingies are owl:sameAs, then presumably they have same IP- related characteristics, owners, creation dates etc? Does that mean Cycorp owns UMBEL? Dan, No, it implies that in the UMBEL data space you have equivalence between Classes used to define UMBEL subject concepts (subject matter entities) and OpenCyc. Exact Damian, does that mean Cycorp owns UMBEL? : no. Dan wanted to show the strongness of the sameAs property with such a conclusion But the current fact is that UMBEL is a subset of OpenCyc (that is a subset of Cyc) where each UMBEL subject concept is an equivalentClass to a OpenCyc class. No sameAs relationship exists between umbel subject concepts and opencyc classes: everything happen at the class level. Now, what happen for UMBEL named entities? (invididual of classes). Some UMBEL named entities are sameAs dbpedia resources, yago resources, etc. However, the question is: does that mean that dbpedia or yago own umbel named entities? No. One set of named entities that describes named entities that appear on Wikipedia (and another one describe named entities described in the john peel sessions dataset from the bbc). On its side, DBpedia has done the same thing: it described individual of classes that appear on Wikipedia. So, if a sameAs statement is done between the UMBEL named entity (that is an individual of a class; so a candidate to use sameAs) that describe Abraham Lincoln for example, is sameAs, DBPedia's resource describing Abraham_Lincoln; does that mean that the meta data that describe the creator of the description of the resource is the same too? No since as other said on this thread: this meta-data would be described as its own resource. In any case, sameAs is a really strong statement to link instances of classes together. It is why we introduced the property umbel:isLike in umbel for example (still a test and feedbacks are welcome :) ) Thanks, Take care, Fred
Re: Drilling into the LOD Cloud
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [sorry, forgot to reply-all] Peter Ansell wrote: | That is fine for classes, but how do you map individuals without metadata side-effects? Looking at my previous answer again I think I should take another run at this :-) One way of thinking about equivalence is in terms of substitution: if :x :equiv :y when is it safe to substitute :x with :y? The default is: it's not safe (obviously). :x equivalentClass :y - safe when used as a class (e.g. rdf:type :x) :x sameAs :y - always safe (watch out!) :x sameConceptAs :y - safe in subject positions :x sameWorkAs :y - safe for author, creation date :x sameManifestationAs :y - safe for the the above, and length (?) Does that help? Damian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI4NdRAyLCB+mTtykRAppqAJ9kzkWgcWt0zeWfWdMfWwqtdhoblwCeNCWH 54J20+PaNd1xmCmcFLs9DN8= =/gW2 -END PGP SIGNATURE-
Re: Drilling into the LOD Cloud
On Mon, Sep 29, 2008 at 2:08 PM, Dan Brickley [EMAIL PROTECTED] wrote: Damian Steer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [sorry, forgot to reply-all] Peter Ansell wrote: | That is fine for classes, but how do you map individuals without metadata side-effects? Looking at my previous answer again I think I should take another run at this :-) One way of thinking about equivalence is in terms of substitution: if :x :equiv :y when is it safe to substitute :x with :y? The default is: it's not safe (obviously). :x equivalentClass :y - safe when used as a class (e.g. rdf:type :x) :x sameAs :y - always safe (watch out!) :x sameConceptAs :y - safe in subject positions do you mean subject in the 'topic, dc:subject' sense, rather than subject/predicate/object sense? On first reading I thought you meant the latter, which would be problematic since any inverse of property can flip values into 'object' role. So assuming the former, I quite agree. Also thanks for expanding on what I meant. I was indeed picking a strong example to emphasise my (under articulated) case. Using an owl:sameAs claim between independently developed classes and properties is almost always misleading, confusing and untrue. So yup I agree that application-specific properties such as these are often more useful. Also btw folks there is no such thing as dc:author. It was changed in the mid-late 1990s to be dc:creator, so as to better cover non-written creations such as images, museum artifacts etc. So best to avoid/fix it in mail threads before 'dc:author' ends up getting mentioned in books etc. Oops. Made a quick search and I don't use author anywhere in my codebase ( I use creator ). But for some reason it is still sticking in my mind ( band, music, author ) If it shows up in a book I'll feel really guilty, as the material author of that crime ( or should I say creator )... This brings up another point ( re. retroactive edition ). Why haven't we found a replacement for mailing lists? Dog fooding anyone? ( rhetoric question perhaps. don't reply on this thread or it will go seriously off topic ). Thx, A cheers, Dan :x sameWorkAs :y - safe for author, creation date :x sameManifestationAs :y - safe for the the above, and length (?) Does that help? Damian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI4NdRAyLCB+mTtykRAppqAJ9kzkWgcWt0zeWfWdMfWwqtdhoblwCeNCWH 54J20+PaNd1xmCmcFLs9DN8= =/gW2 -END PGP SIGNATURE- -- Aldo Bucchi +56 9 7623 8653 skype:aldo.bucchi twitter:aldonline http://aldobucchi.com/ http://univrz.com/
Re: Drilling into the LOD Cloud
This is definitely too late, but still.. Have you seen http://der-mo.net/ 's visualizations? On Mon, Sep 22, 2008 at 6:43 AM, Ed Summers [EMAIL PROTECTED] wrote: I am doing a presentation (tomorrow) on lcsh.info at DC2008, and of course (hat tip to PaulMiller) I'm using the LOD Cloud to illustrate how you all actually putting RDF to work. While the LOD Cloud is great for visualizing the different data sets that are getting linked together, I was wondering if anyone happens to have some visualizations of the type of links that exist between resources in the LOD Cloud. I guess what I'm thinking of is the usual graph illustration with nodes, arcs, etc -- with resource URIs that live in different namespaces: geonames, dbpedia, etc ... I'd like to illustrate the importance of those linking assertions. If you have something handy, I'd love to use it, and spend more time drinking beer here in Berlin :-) //Ed -- Aldo Bucchi +56 9 7623 8653 skype:aldo.bucchi twitter:aldonline http://aldobucchi.com/ http://univrz.com/
Re: Drilling into the LOD Cloud
Kingsley Idehen wrote: Ed Summers wrote: On Mon, Sep 22, 2008 at 1:28 PM, Giovanni Tummarello [EMAIL PROTECTED] wrote: I really support your idea for a lod cloud that's actually useful to write queries, i promise we'll do the best from sindice to deliver one such a thing. That sounds like a great idea for a service. Right now I just need a little diagram that illustrates the links between resources in the LOD cloud; and the diversity of descriptions from each provider. But, I guess I should stop begging on here, and just create it eh? Thanks for the feedback, //Ed Ed, Are you not able to add additional rdf:type links between DBpedia and the following: 1. Yago 2. OpenCyc 3. UMBEL Then between UMBEL and OpenCyc: 1. owl:sameAs 2. owl:equivalentClass If these thingies are owl:sameAs, then presumably they have same IP-related characteristics, owners, creation dates etc? Does that mean Cycorp owns UMBEL? Then between OpenCyc and Wordnet: 1. owl:sameAs Ditto... cheers, Dan
Re: Drilling into the LOD Cloud
Dan Brickley wrote:
Kingsley Idehen wrote:
Ed Summers wrote:
On Mon, Sep 22, 2008 at 1:28 PM, Giovanni Tummarello
[EMAIL PROTECTED] wrote:
I really support your idea for a lod cloud that's actually useful to
write queries, i promise we'll do the best from sindice to deliver one
such a thing.
That sounds like a great idea for a service. Right now I just need a
little diagram that illustrates the links between resources in the LOD
cloud; and the diversity of descriptions from each provider. But, I
guess I should stop begging on here, and just create it eh?
Thanks for the feedback,
//Ed
Ed,
Are you not able to add additional rdf:type links between DBpedia
and the following:
1. Yago
2. OpenCyc
3. UMBEL
Then between UMBEL and OpenCyc:
1. owl:sameAs
2. owl:equivalentClass
If these thingies are owl:sameAs, then presumably they have same
IP-related characteristics, owners, creation dates etc?
Does that mean Cycorp owns UMBEL?
Dan,
No, it implies that in the UMBEL data space you have equivalence between
Classes used to define UMBEL subject concepts (subject matter entities)
and OpenCyc.
Simple examples via SPARQL against DBpedia using the SPARQL endpoint:
http://dbpedia.org/sparql :
-- Get DBpedia Entities of Type opencyc:Motorcycle where the
dbpedia:name contains pattern: BMW
define input:inference 'http://dbpedia.org/resource/inference/rules/umbel#'
prefix umbel: http://umbel.org/umbel/sc/
prefix dbpedia: http://dbpedia.org/property/
prefix opencyc: http://sw.opencyc.org/2008/06/10/concept/en/
select ?s
where
{
?s a opencyc:Motorcycle.
?s dbpedia:name ?n.
?n bif:contains BMW.
}
-- Get DBpedia Entities of Type umbel:Motorcycle where the dbpedia:name
contains pattern: BMW
define input:inference 'http://dbpedia.org/resource/inference/rules/umbel#'
prefix umbel: http://umbel.org/umbel/sc/
prefix dbpedia: http://dbpedia.org/property/
prefix opencyc: http://sw.opencyc.org/2008/06/10/concept/en/
select ?s
where
{
?s a umbel:Motorcycle.
?s dbpedia:name ?n.
?n bif:contains BMW.
}
Both queries return the same results even though in DBpedia you only
have entities of type umbel:Motorcycle as shown here:
http://dbpedia.org/resource/BMW_R75 .
Courtesy of UMBEL and UMBEL inference rules applied to DBpedia, we can
now expand the scope of existing DBpedia entities by exploiting
relationships that exist across the Classes exposed via rdf:type.
Thus, via rdf:type we are able to cross over from the instance realm
to the data dictionary realm, and once in the data dictionary realm
expand our horizons via class level relationships covering
equivalence and the broader and narrower transitive relationships in the
Class Hierarchy.
So OpenCyc doesn't own UMBEL, it is simply associated with UMBEL by
being part of the data dictionary oriented Linked Data Space that UMBEL
delivers :-)
Kingsley
Then between OpenCyc and Wordnet:
1. owl:sameAs
Ditto...
cheers,
Dan
--
Regards,
Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen
President CEO
OpenLink Software Web: http://www.openlinksw.com
Re: Drilling into the LOD Cloud
- Damian Steer [EMAIL PROTECTED] wrote: From: Damian Steer [EMAIL PROTECTED] To: Kingsley Idehen [EMAIL PROTECTED] Sent: Monday, September 29, 2008 7:30:30 AM GMT +10:00 Brisbane Subject: Re: Drilling into the LOD Cloud On 28 Sep 2008, at 19:01, Kingsley Idehen wrote: Dan Brickley wrote: Kingsley Idehen wrote: Then between UMBEL and OpenCyc: 1. owl:sameAs 2. owl:equivalentClass If these thingies are owl:sameAs, then presumably they have same IP- related characteristics, owners, creation dates etc? Does that mean Cycorp owns UMBEL? Dan, No, it implies that in the UMBEL data space you have equivalence between Classes used to define UMBEL subject concepts (subject matter entities) and OpenCyc. I think Dan's point is that owl:sameAs is a very strong statement, as illustrated by the ownership question. If opencyc:Motorcyle owl:equivalentClass umbel:Motorcycle then they have the same extension. Informally, any use you make of one as a class can be replaced by the other without changing the meaning of the whole. However if the are owl:sameAs they name the same thing, so dc:creationDate, dc:creator, cc:license, rdfs:isDefinedBy etc etc are the same for each, which strike me as unhelpful side effects. owl:equivalentClass is the vocabulary mappers' friend :-) That is fine for classes, but how do you map individuals without metadata side-effects? Is there a need for a metadata term type which is locked to the URI that it is defined against and does not carry with sameAs? A reasoner could implement such a thing for terms which it knows are not to be applied against other URI's (above the individual/class model). Peter
Re: Drilling into the LOD Cloud
I think you're overlooking something If you're using dc:author to state http://dbpedia.org/resource/R%C3%B6yksopp dc:author example:me ( which translates to: I *created Royksopp*, the music band ) And then Umbel states that *they created* the music band ( I made this up for the example ). http://umbel.org/umbel/ne/wikipedia/R%C3%B6yksopp dc:author ex:someoneElse . you will indeed run into problems when equating the two IDs. http://dbpedia.org/resource/R%C3%B6yksopp owl:sameAs http://umbel.org/umbel/ne/wikipedia/R%C3%B6yksopp But, AFAIK, this is *incorrect usage of dc:author* and not a design flaw re. owl:sameAs. Luckily, neither UMBEL nor DBpedia seem to be using dc:author incorrectly. Authorship metadata should not be attached to the ID for the concept, but to the vocabulary namespace or through other indirection. Which brings up another point: how do you state that a URI belongs to a given vocabulary. - URI opaqueness plays against here - is this really something we want/need? - ... If what you intend to equate is a document ( which usually have dc:* metadata ) with another doc that has different metadata, stop and rethink it. You might be wanting to equate the concepts they reference. A On Sun, Sep 28, 2008 at 6:30 PM, Damian Steer [EMAIL PROTECTED] wrote: On 28 Sep 2008, at 19:01, Kingsley Idehen wrote: Dan Brickley wrote: Kingsley Idehen wrote: Then between UMBEL and OpenCyc: 1. owl:sameAs 2. owl:equivalentClass If these thingies are owl:sameAs, then presumably they have same IP-related characteristics, owners, creation dates etc? Does that mean Cycorp owns UMBEL? Dan, No, it implies that in the UMBEL data space you have equivalence between Classes used to define UMBEL subject concepts (subject matter entities) and OpenCyc. I think Dan's point is that owl:sameAs is a very strong statement, as illustrated by the ownership question. If opencyc:Motorcyle owl:equivalentClass umbel:Motorcycle then they have the same extension. Informally, any use you make of one as a class can be replaced by the other without changing the meaning of the whole. However if the are owl:sameAs they name the same thing, so dc:creationDate, dc:creator, cc:license, rdfs:isDefinedBy etc etc are the same for each, which strike me as unhelpful side effects. owl:equivalentClass is the vocabulary mappers' friend :-) Damian -- Aldo Bucchi +56 9 7623 8653 skype:aldo.bucchi twitter:aldonline http://aldobucchi.com/ http://univrz.com/
Re: Drilling into the LOD Cloud
On Mon, Sep 22, 2008 at 1:28 PM, Giovanni Tummarello [EMAIL PROTECTED] wrote: I really support your idea for a lod cloud that's actually useful to write queries, i promise we'll do the best from sindice to deliver one such a thing. That sounds like a great idea for a service. Right now I just need a little diagram that illustrates the links between resources in the LOD cloud; and the diversity of descriptions from each provider. But, I guess I should stop begging on here, and just create it eh? Thanks for the feedback, //Ed
Re: Drilling into the LOD Cloud
Yep, that's the plan .. just wondering if someone had some slideware content to that effect already :-) //Ed On Mon, Sep 22, 2008 at 4:42 PM, Kingsley Idehen [EMAIL PROTECTED] wrote: Ed Summers wrote: On Mon, Sep 22, 2008 at 1:28 PM, Giovanni Tummarello [EMAIL PROTECTED] wrote: I really support your idea for a lod cloud that's actually useful to write queries, i promise we'll do the best from sindice to deliver one such a thing. That sounds like a great idea for a service. Right now I just need a little diagram that illustrates the links between resources in the LOD cloud; and the diversity of descriptions from each provider. But, I guess I should stop begging on here, and just create it eh? Thanks for the feedback, //Ed Ed, Are you not able to add additional rdf:type links between DBpedia and the following: 1. Yago 2. OpenCyc 3. UMBEL Then between UMBEL and OpenCyc: 1. owl:sameAs 2. owl:equivalentClass Then between OpenCyc and Wordnet: 1. owl:sameAs -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President CEO OpenLink Software Web: http://www.openlinksw.com
