on using owl:sameAs - can you use skos:exactMatch instead?
msksys
Thanks for the 'data' contribution to Semantic Web.
The following comment in your blog article on releasing the first
batch of links between NYT and linked data
http://open.blogs.nytimes.com/2009/10/29/first-5000-tags-released-to-the-linked-data-cloud/#comment-23941
identified the issue of using owl:sameAs and its implication to
rightsHolder.
Can you use skos:exactMatch?
This has the same meaning while does not result in the inference
owl:sameAs provides. In most cases this data is linking/matching
instances and not class concepts.
- Srikanth
Evan Sandhaus <sandhes@nytimes.com>
I like this suggestion, but I've also been urged to consider attaching
a skos:conceptScheme to the records and applying the license to that
scheme.
What do you think is the right approach?
~Evan
On Oct 30, 12:42 pm, msksys <msk...@gmail.com> wrote:
> Hi:
>
> Thanks for the 'data' contribution to Semantic Web.
>
> The following comment in your blog article on releasing the first
> batch of links between NYT and linked data
>
msksys
I don't known the implications of associating license to the data as I
am not sure how it is be used in applications.
If I understand correctly, the combination of owl:sameAs and
rightsHolder and what it entails was the main issue.
I don't think it will be a problem if you keep dcterms:rightsHolder at
concept level and use skos:exactMatch instead of owl:sameAs.
- Srikanth
On Oct 30, 9:51 am, "Evan Sandhaus <sand...@nytimes.com>"
>
> - Show quoted text -
Hugh Glaser
Actually, when I went looking for the links (for sameAs.org) I had
expected to find skos:exactMatch and skos:closeMatch, as Evan had said
that they used skos, and was a little surprised to find owl:sameAs.
I would have accepted skos:exactMatch as equivalence links for
sameAs.org, by the way, and might even have taken skos:closeMatch if
they looked right.
So from my point of view, skos:exactMatch would be fine, and I think
you might avoid quite a bit of hassle by doing that? :-)
Mind you, to do it properly, I think you need to make sure that the
doamin and range are skos concepts.
Dan Brickley
I think there's a lack of clarity on whether there are any classes
that skos:Concept is truely disjoint with.
I have seen idioms in SKOS data (though I don't encourage it) where eg
a place or person concept also carries properties of that individual
(eg. age, location). Also sometimes people try to mix in OWL so a SKOS
concept for 'Dog' might also be an RDFS/OWL class. These are natural
explorations as the worlds of traditional thesauri and classification
systems blend into the more data-oriented RDFy stuff, but it makes it
hard to know quite what to recommend re skos:closeMatch...
Dan
Evan Sandhaus
skos:exactMatch and other skos:semanticRelation(s) is skos:concept and
the resources I'm currently mapping to ( at dbpedia and freebase) are
not of rdf:type skos:concept. Thus in these instances, as Hugh
suggested, it is inappropriate for us to link to resources that are
not of type skos:concept using skos:semanticRelation(s) predicates.
As a consequence, I seem to be left with two options, only one of
which seems good to me. Option 1 (the good one), restructure my RDF
to resolve the licensing and metadata issues and continue to use
owl:sameAs (and perhaps rdf:seeAlso where appropriate). Or option 2
( the bad one), coin my own predicates for describing the links from
my data to external resources. I am strongly disinclined to pursue
option 2, so I will continue to investigate option 1.
That being said, I can imagine instances where the
skos:semanticRelations(s) are appropriate (e.g. when linking to LOC
subject headings). So I am not entirely ruling out their future use,
just necessarily restricting it.
Thoughts?
Evan
============
Evan Sandhaus
Semantic Technologist
New York Times Research + Development
Kingsley Idehen
> The domain and range of skos:broader, skos:narrower, skos:closeMatch,
> skos:exactMatch and other skos:semanticRelation(s) is skos:concept and
> the resources I'm currently mapping to ( at dbpedia and freebase) are
> not of rdf:type skos:concept. Thus in these instances, as Hugh
> suggested, it is inappropriate for us to link to resources that are
> not of type skos:concept using skos:semanticRelation(s) predicates.
>
> As a consequence, I seem to be left with two options, only one of
> which seems good to me. Option 1 (the good one), restructure my RDF
> to resolve the licensing and metadata issues and continue to use
> owl:sameAs (and perhaps rdf:seeAlso where appropriate).
If you are talking about the same thing that has a known (and even
strong) identifier elsewhere, and the entity types are the same, please
use owl:sameAs. It your data space, and your claim to make.
Always remember the great "nearly pregnant" analogy in Pat Hayes Blogic
presentation.
The URI for owl:sameAs [1] is a live demonstration of why namespaces and
de-referencable URIs matter. You can de-reference [2] exactly what it
means :-) Note, it isn't symmetrical or transitive etc.. It is as
described, just a way of indicating, that from your vantage point (your
Linked Data Space): Entities X & Y refer to the same thing i.e.,
co-reference.
Links:
1. http://www.w3.org/2002/07/owl#sameAs
2.
http://linkeddata.uriburner.com/about/html/http/www.w3.org/2002/07/owl%01sameAs
--
Regards,
Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO
OpenLink Software Web: http://www.openlinksw.com