W3C home > Mailing lists > Public > public-lld@w3.org > June 2011

Review of Relevant Technologies section

From: Jon Phipps <jonp@jesandco.org>
Date: Wed, 22 Jun 2011 21:30:13 -0400
Message-ID: <BANLkTikgik_jcSPQ0TKQ-pb_zz-xfX_VEQ@mail.gmail.com>
To: tom@tombaker.org, public-lld <public-lld@w3.org>
Cc: Antoine Isaac <aisaac@few.vu.nl>, emmanuelle.bermes@bnf.fr
Folks,

I was asked to review the 'Relevant Technologies' section...

I have some general comments at this point, and I think some of the more
specific problems might be subsumed if the general problems are addressed.


   1. A great deal of time has been spent gathering and organizing relevant
   Use Cases and it seems to me that this section in particular should attempt
   to define 'relevance' in terms that would show the relevance of the
   available technologies to the specific categories of Use Cases, either by
   organization or by direct reference in the text.
   2. There's considerable confusion regarding RDF and Linked Data, often
   treating the two technologies as synonymous. Although they share some
   features, such as the centrality of URIs to the technology, Linked Data
   doesn't require RDF either as transport, storage or data model. I agree that
   there are distinct advantages to using the RDF data model to express LLD in
   the transport layer and for aggregation, but this shouldn't be promoted to
   the level of a requirement, nor should the advantages of RDF be presented as
   the same advantages of Linked Data. This happens throughout the report, not
   just in this section, and it would be worthwhile to review all of the
   sections for clarity with respect to this difference. If it's the
   recommendation of this group that LLD be restricted to RDF (as the
   definition of LLD in the 'scope' section states), then that needs to be an
   explicit and clearly defined prescription and its implications taken into
   consideration.
   3. Related to #2, it would be useful to be explicit about the hierarchy
   of technologies supported by Linked Data as spelled out in TBL's
   'principles' document and his '5-star-rating' compliance as it directly
   addresses technologic relevance.

Some specifics:

   - Discrete and bulk access to information
      - Cool URIs have 2 requirements: 1) be on the web (http) and 2) be
      unambiguous (one URI can't stand for both a document and a real-world
      object). This is quite different from "raw RDF can be easily and
      automatically negotiated and rendered into an HTML format for human
      (browser) consumption". Linked data's distinction is its
narrowing of semweb
      focus to Cool URI requirement #1 and its divergence from some of the more
      stringent Artificial Intelligence-driven requirements of semweb.
      - "... the atomic nature of Linked Data http URIs makes it impractical
      for high volume network access" is arguably as untrue as saying that http
      URIs in general are impractical for high volume network access. It also
      conflicts with the value of http URIs described in the introductory
      paragraph to this section.
      - This paragraph doesn't effectively describe the technologic
      relevance of either discrete or bulk access to library data.
   - Linked Data front-ends
      - "... typical XML documents". In the context of library linked data a
      better comparison might be made to MARC21
      - What does "mash up" mean?
      - This paragraph is an instance of RDF/Linked Data confusion and seems
      to be substituting Linked Data for RDF
      - There's no mention of the integration of RDF layers on existing data
      stores, like Oracle and DB2 and a simple Google Scholar search (
      http://bit.ly/mjBMQl) invites distillation into a few sentences a
      discussion of RDF and 'traditional' data stores.
   - Tools for data designers
      - There's no mention of UML and its relationship to data modeling for
      RDF, or the best practices of the Dublin Core Singapore Framework and the
      Dublin Core Abstract Model's integration of RDF-friendly domain modeling.
      - This is the first mention of "domain-specific vocabularies" that
      elsewhere appear to be described as "metadata element sets".
This should be
      made consistent or a clearer distinction made.
      - OWL could as easily be seen as an impediment to the production of
      RDF. Rather than promoting OWL it might be better to provide a
more neutral
      and balanced description of the technology, specific to library
linked data
      in RDF format.
      - This paragraph is also an instance of RDF/Linked Data confusion

At this point I have more than run out of time to continue, I'm already very
late with this review, and I'm not at all sure that the level of detailed
review in the sections above is what's required. If you'd like me to
continue with that level of detail for the rest of the section, I may be
able to provide that before the next meeting. But I'm attending ALA Annual
for the next week and my dance card is quite full. Hopefully this represents
a useful start.
-- 
Jon Phipps
Received on Thursday, 23 June 2011 01:31:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 23 June 2011 01:31:33 GMT