I got some drawings by Rembrandt in a British Museum database, and some paintings by Rembrandt in a RKD database. He's referred to as
The current representation is:
Aside: If you look in VIAF, you'll see Rembrandt correlated between 19 sources, including national libraries and Getty ULAN. There's a thousand names and a bunch of extra info about him.
If you look at the VIAF RDF record, you'll see he's represented as a
There are also some owl:sameAs links equating the
It would have been great if the BM and RKD thesauri were correlated to VIAF but they're not. end-aside
The question: which is the best way to correlate
I know that both the SKOS Primer and Reference say one should use
If I use
What's your advice?
owl:sameAs has potentially unwelcome inferences. Imagine that I have a term "Monkey" which was added to my thesaurus today, and I claim it's owl:sameAs the concept "Monkey" in a dictionary that somebody else published many years ago.
The skos:Concept for a monkey doesn't represent an actual monkey, or the class of all monkeys. Think of it more as representing an entry in an a thesaurus, dictionary, encyclopaedia or catalogue.
answered 05 May '12, 17:34
The matter has been discussed many times on W3C lists, I won't tell a lot more. The short answer is that in the SKOS context, SKOS matching properties make much sense than the owl:sameAs one. owl:sameAs was existing at the time we finished SKOS, if it had been better we'd have picked it.
The arguments in the SKOS Primer (http://www.w3.org/TR/skos-primer/#secmapping) are not as weak as you claim. These are example where using owl:sameAs results in invalid SKOS data. And not the kind of SKOS data only used for vocabulary management: having non-unique prefLabels will break many data consumption scenarios.
Side notes: - Europeana is using owl:sameAs, yes, but not between SKOS Concepts - there is a foaf:focus property which can be interesting to links SKOS Concepts to "real" entities they represent.
answered 10 Dec '12, 07:06
Overall I think owl:sameAs, with standard semantics, is not suitable for exchange across boundaries between semantic systems. If, for instance, you're scraping triples off the floor and throwing them into a processing chain, owl:sameAs will definitely give you entailments you don't work.
Now, inside a perimeter that you control, the story is different. owl:sameAs behaves a particular way in your triple store and if you like what owl:sameAs does, then go ahead and use it.
I say it that way, because you're using OWLIM, and OWLIM implements owl:sameAs in a way that may or may not be standards correct or mathematically correct but that is certainly "correct" for building real applications. The case for owl:sameAs is much weaker if you use other tools.
Personally I've dealt with these problems by creating a wrapper that normalizes identifiers that cross the system perimeter but this doesn't address all the problems involved when two concepts in the KB get merged,
answered 08 May '12, 15:58
Antoine, I am also comfortable with having a person be both Person and skos:Concept, but if I cannot use sameAs then there's little value in it being a skos:Concept.
Seems to me VIAF got it right
First they have a main URI that's foaf:Person and all URIs used in data (eg national library bibliographies) are given as sameAs (or "=" in Turtle):
This would mean that none of the source URIs is a skos:Concept.
Then they copy all labels from all the sources to foaf:name. Unfortunately they lose preferredness info, but I don't know how could they pick one of the source's prefLabel as globally preferred...
Finally they have one skos:Concept per source, with foaf:focus to the main URI:
So they use skos:Concept and foaf:focus only for "thesaurus bookkeeping info", but it seems the intention is to use the main URI (and sameAs source URIs) in business data.
The BnF data model also uses foaf:focus:
So... the answer is: don't use skos:Concept in business data, use other URIs that are amenable to sameAs. Or else, implement extra rules that propagate business relations across skos:exactMatch.
Note: it seems to me we need to assume the following rule: