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: Wed, 7 Apr 2010 09:14:15 +1000
Message-ID: <i2za1be7e0e1004061614l80d3d2a2tc01980247e969793@mail.gmail.com>
To: Leigh Dodds <leigh.dodds@talis.com>
Cc: Linking Open Data <public-lod@w3.org>
In the Annotation publishing pattern section there is the following statement:

"It is entirely consistent with the Linked Data principles to make
statements about third-party resources."

I don't believe that to be true, simply because, unless users are
always using a quad model (RDF+NamedGraphs), they have no way of
retrieving that information just by resolving the foreign identifier
which is the subject of the RDF triple. They would have to stumble on
the information by knowing to retrieve the object URI, which isn't
clear from the pattern description so far. In a triples model it is
harmful to have this pattern as Linked Data, as the statements are not
discoverable just knowing the URI.

If the idea of the book is to point to quads as the preferred model
for publishing Linked Data then it may be okay because the named graph
is in each statement to indicate where the statement came from so
users just have to recognise that URIs in triples are not linked to
retrieval locations, and they should keep the quad extension and use
that for retrieval. It seems like a stretch to have this as a valid
alternative instead of the easier (in Linked Data terms) pattern of
creating new URI's that are equivalent to the other URI, just with one
or more extra statements.

In the Equivalent Links publishing pattern section there is the
following statement:

"The relations allow for more fuzzy notions of equivalence and have
weaker semantics: skos:exactMatch declares two concepts to be the same
but doesn't imply that all statements about one concept are also true
of another."

Should indicate there that SKOS implies that all of the URIs are
philosophically just concepts such as those that exist in taxonomies.
To use skos:exactMatch one has to follow the SKOS model through or it
doesn't fit, as with the OWL model.

Could also explain that mixing OWL and SKOS may not be desirable as
SKOS puts importance on URI's and logical statements where OWL
completely abstracts over URI's, so there is no knowing whether
statements actually originally contained the URI, or whether they were
published using the proxy pattern and infact some statements should be
interpreted just using the SKOS model and doing it using the SKOS
model would be inconsistent with the original idea.

In some cases the equivalent links used with the Annotation pattern
meana that publishers do not necessarily have control over the
statements using their Linked Data URI's, although others may use
their URI's to imply different things. Explaining this lack of
authority may be good, or could change the recommendations about the
Annotation publishing pattern so that users are not encouraged to add
extra statements directly to other resources without using some sort
of equivalence that requires some sort of reasoning (eg, OWL) to take
away the reliance on the original Linked Data URI's that are used to
get to the RDF statements.



On 7 April 2010 01:10, Leigh Dodds <leigh.dodds@talis.com> wrote:
> Hi folks,
> Ian Davis and I have been working on a catalogue of Linked Data
> patterns which we've put on-line as a free book. The work is licensed
> under a Creative Commons attribution license.
> This is is still a very early draft but already contains 30 patterns
> covering identifiers, modelling, publishing and consuming Linked Data.
> http://patterns.dataincubator.org
> More background at [1]. We'd be interested to hear your comments, and
> hope that it can become a useful resource for the growing community of
> practitioners.
> Cheers,
> L.
> [1]. http://www.ldodds.com/blog/2010/04/linked-data-patterns-a-free-book-for-practitioners/
> --
> Leigh Dodds
> Programme Manager, Talis Platform
> Talis
> leigh.dodds@talis.com
> http://www.talis.com
Received on Tuesday, 6 April 2010 23:14:52 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:29:48 UTC