RE: Review of Relevant Technologies section

Jon,

Your initial review still needs to be examined, but here is a comment on a message from earlier today:

> If we make library ld synonymous with rdf then we close the door on lld
> in many, many contexrs. It's not our job as an xg to close doors but to
> ask which ones need to be opened. Although I'm completely committed to
> lld in rdf, I'd be happy to see marc available as linked data
> (completely possible) if that's a good place to start. TBL has made
> this point in many different contexts and I prefer to think that it
> might be a good point.

Publishing MARC/XML records at discrete http URIs would satisfy TBL's point of encouraging "open data". If you're suggesting that the MARC element set could be redefined as an RDF vocabulary, that's certainly true too. Here's the outline:

@prefix marc: <http://www.loc.gov/MARC21/slim> .

marc:record a owl:Class .
marc:leader a owl:DatatypeProperty.
marc:controlfield a owl:DatatypeProperty.
marc:datafield a owl:ObjectProperty.
marc:subfield a owl:ObjectProperty.
marc:tag a owl:DatatypeProperty.
marc:code a owl:DatatypeProperty.
marc:ind1 a owl:DatatypeProperty.
marc:ind2 a owl:DatatypeProperty.

I suspect that most of us would agree a literal transform of MARC/XML into MARC/RDF would be a wasted effort.

There are efforts to map MARC Bibliographic/Authority data into more sensible ontological models (FRBR/RDA/SKOS/etc), but that starts to cross the line into the vocabularies section. The relevant technologies section does mention OWL's vocabulary mapping capabilities <http://www.w3.org/TR/2004/REC-owl-guide-20040210/#OntologyMapping>, but the MARC element set is presumably too alien for these basic principles to be applied. It occurs to me, though, that we overlooked XSLT as a relevant technology so I added a mention of it. Here's the diff:

http://www.w3.org/2005/Incubator/lld/wiki/index.php?title=Draft_Relevant_Technologies&diff=5176&oldid=5144


Jeff

> 
> The current report makes many such unnecessary, premature, and ill-
> considered assertions. This group is supposed to be investigating
> issues and identifying questions that need answering through broader
> discussion and invstigation, not proceding to provide the answer to the
> questions before they're asked.
> 
> Or do I completely misunderstand the charter?
> 
> Jon Phipps
> Sent from my LG phone
> 
> Karen Coyle <kcoyle@kcoyle.net> wrote:
> 
> I wonder if the W3C context of the group doesn't increase the tendency
> to conflate LD and RDF. The Linking Open Data project[1] states
> clearly that their concept of LD is in RDF:
> 
> "The goal of the Linking Open Data project is to build a data commons
> by making various open data sources available on the Web as RDF and by
> setting RDF links between data items from different data sources."
> 
> This makes me think that we need to say somewhere early on in our
> report that we are speaking of LD in that W3C sense of LD in RDF -- or
> to say that we are NOT assuming that. My impression has been that the
> assumption of RDF is there in our discussions (right or wrong as that
> is).
> 
> kc
> 
> [1]
> http://www.w3.org/wiki/SweoIG/TaskForces/CommunityProjects/LinkingOpenD

> ata
> 
> Quoting Jon Phipps <jonp@jesandco.org>:
> 
> > 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
> >
> 
> 
> 
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net

> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
> 
> 
>

Received on Monday, 27 June 2011 03:28:57 UTC