W3C home > Mailing lists > Public > public-lod@w3.org > April 2010

Re: Announce: Linked Data Patterns book

From: Peter Ansell <ansell.peter@gmail.com>
Date: Thu, 8 Apr 2010 09:08:59 +1000
Message-ID: <x2ua1be7e0e1004071608ze946e368g55ccef2f42836ee3@mail.gmail.com>
To: Vasiliy Faronov <vfaronov@gmail.com>
Cc: Ian Davis <lists@iandavis.com>, Leigh Dodds <leigh.dodds@talis.com>, Linking Open Data <public-lod@w3.org>
On 7 April 2010 20:07, Vasiliy Faronov <vfaronov@gmail.com> wrote:
> Peter Ansell wrote:
>> If there was an annotation, there should be an equivalency
>> relationship defined to the original URI, so Y would link back to X,
>> and Z would link back to Y, and possibly X.
>
> But if Y and Z are for two independent annotations of X, should they
> link to each other?
>
> If yes, I don't see how really different this is from linking X to the
> documents containing the annotations (rdfs:seeAlso). Both ways rely on
> some publisher(s) being willing to link to some extraneous data.
> Moreover, in the X-only case, only the original authority needs to do
> that, whereas in the many-URI case, we need multiple links all over the
> place to connect the annotations to each other and make them
> discoverable.

It is not necessarily a technical issue. It is also not necessarily
extraneous data. If all original authorities were open to adding links
to any annotations then there wouldn't be an issue, but as they are
not necessrily that open to the idea, it would be nice to emphasise
that they do not have to be involved in the process. Sure it is
simpler if they do...

> If no, then neither Y nor Z are discoverable from anywhere in the LD
> web, and there's no need to mint these URIs in the first place.

I don't see why Y and Z shouldn't link to each other, if they know
about each other. It may be a social issue still, as the independent
annotations may still not accept each other.

Cheers,

Peter
Received on Wednesday, 7 April 2010 23:09:32 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:26 UTC