- From: Leigh Dodds <leigh@ldodds.com>
- Date: Fri, 1 Jun 2012 15:45:50 +0100
- To: Bradley Allen <bradley.p.allen@gmail.com>
- Cc: Antoine Isaac <aisaac@few.vu.nl>, Tim Berners-Lee <timbl@w3.org>, "public-lod@w3.org community" <public-lod@w3.org>
Hi, On Fri, Jun 1, 2012 at 3:30 PM, Bradley Allen <bradley.p.allen@gmail.com> wrote: > Leigh- This is great. The question that comes up for me out of what you've > written for unpublishing brings me back to Antoine's question: is it > appropriate to use a relation other than owl:sameAs that more specific to > the domain of the affected datasets being mapped, or is the nature of > unpublishing such that one would, as opposed to my reasoning earlier, be as > broad as possible in asserting equivalence, and use owlsameAs in every such > case? Really interesting question, and this might prompt me to revise the pattern :) So, generally, I advocate using the appropriate equivalence relation that relates to a specific domain. As I wrote in [1] its best to use the most appropriate equivalence link, as they have varying semantics. But for the unpublishing use case I think I'd personally lean towards *always* using owl:sameAs at least in the case where we are returning a 301 status code. I've previously come to the conclusion [2] that a 301 implies a sameAs statement. The intent seems very similar to a sameAs. Rewriting local links to use a new location is very similar to smushing descriptions in an RDF dataset such that statements only relate to the new URI. However I can see arguments to the effect that the new authority might have a slightly different definition of a resource than the original publisher, such that an owl:sameAs might be inappropriate. That's why I left the advice in the pattern slightly open ended: I think it may need to be evaluated on a case by case basis, but owl:sameAs seems like a good workable default to me. Cheers, L. [1]. http://patterns.dataincubator.org/book/equivalence-links.html [2]. http://www.ldodds.com/blog/2007/03/the-semantics-of-301-moved-permanently/
Received on Friday, 1 June 2012 14:46:24 UTC