All

Expressing library metadata schemas in RDF to support linked data in the
Semantic Web has identified requirements for several types of named
graph/DCAP features/data lenses:

* Aggregated statements, e.g. the publication statement composed of
publication place, publisher name, publication date: the data can be
aggregated in an unstructured string, a structured string using, say, ISBD
punctuation according to a Syntax Encoding Scheme, or as a named graph
containing the individual component triples. btw, it could be argued that
this represents a blur between Pete's things-in-the-world and
things-in-the-data, as many cataloguers would regard the whole statement as
a thing-in-the-world and its components as things-in-the-data.

* Repeatable "fields" and "subfields", such as a classification statement
containing notation, source, and edition (e.g. MODS): a named graph is
required to keep the component triples together.

* Subsets of properties, designated as mandatory/core, desirable, full, etc
(e.g. RDA, ISBD).: named graphs which overlap or subsume one within the
other. These can be used for validating conformance of instance data.

* Sets of properties that have different constraints in different
applications, such as ISBD's "mandatory if applicable": used for properties
which apply only a specific type of resources, such as music, manuscripts,
etc.

* Subsets of properties meeting user tasks, such as FRBR's Group 1 (WEMI):
the relationships between the subsets need advanced ontological concepts
such as cardinality.

* Sets of properties defining schema-schema mappings between properties in
different namespaces.

These all seem pretty important to me, needing something like DCAM/DCAP
support, with full representation in RDF.

Cheers

Gordon




On 02 February 2012 at 10:53 Bernard Vatant <[log in to unmask]>
wrote:

>
> I've been trying to follow the discussion on DCAM revision, and I must
> confess I've been totally confused so far on what the conversation was all
> about until this post from Pete, which is the first I fully understand and
> agree with.
> To try and understand more other viewpoints, I have a slightly provocative
> question : what is the use of the current DCAM so far, outside the DCMI
> standards?
> If I look from the RDF vocabularies ecosystem, the answer is : nobody AFAIK
> :(
> Compare the reuse of DC Terms and DCAM at
> http://labs.mondeca.com/dataset/lov/details/vocabulary_dc.html
> <http://labs.mondeca.com/dataset/lov/details/vocabulary_dc.html>
> http://labs.mondeca.com/dataset/lov/details/vocabulary_dcam.html
> <http://labs.mondeca.com/dataset/lov/details/vocabulary_dcam.html>
>
> Of course the current content at http://dublincore.org/2010/10/11/dcam.rdf
> <http://dublincore.org/2010/10/11/dcam.rdf> is minimal, but one would think
> that the very generic class dcam:VocabularyEncodingScheme would be re-used
> here and there. One would expect for example things like
>
> skos:ConceptScheme rdfs:subClassOf dcam:VocabularyEncodingScheme
> See discussion
> http://lists.w3.org/Archives/Public/public-esw-thes/2010Jan/0007.html
> <http://lists.w3.org/Archives/Public/public-esw-thes/2010Jan/0007.html>
>
> Is my question coming from a narrow-minded view from RDF land? If yes
> change my question to :
> Who *else" outside RDF land and DCMI standards cares or should care about
> DCAM? And why?
>
> Maybe a preliminary answer to this question would help me understand where
> this debate is bound to.
>
> Thanks for your time
>
> Bernard
>
>
> 2012/2/1 Pete Johnston < [log in to unmask]
> <mailto:[log in to unmask]> >
> >
> > I'm a bit (OK, very!) confused about this analogy between DCAM and SKOS.
> >
> > To me, SKOS has two components:
> >
> > - a model of (a part of) the "world" as made up of concepts, concept
> > schemes, lexical terms etc, which have certain attributes and certain
> > relationships between them
> > - an RDF vocabulary (or two if you distinguish base SKOS and SKOS-XL) for
> > use in creating RDF graphs/triples to describe that "world"
> >
> > SKOS is quite generalised so it can condition how we choose to model our
> > "worlds" in other domains (e.g. do I model my "places" as SKOS Concepts
> > with broader/narrower relations or as spatial things with
> > contains/is-contained-by relations? And so on)
> >
> > But using SKOS doesn't determine/change the nature of my data structures,
> > or the "lens" I apply to those data structures; it only changes my "world"
> > structures: using SKOS I'm still squarely within the framework of RDF graph
> > and triple data structures. SKOS Concept Schemes and Concepts are just more
> > "things" in the "world", but in terms of how my data about those things is
> > "packaged", SKOS Concept Schemes and Concepts are treated exactly the same
> > as any other thing (a foaf:Person, a bibo:Document, a dcmitype:Collection
> > etc etc etc).
> >
> > But - with its notions of Description Set, Description and Statement - DCAM
> > does introduce new data structures, or at least (as I prefer to try to
> > think of it) a new "lens on", a new way of looking at and referring to
> > parts of, the RDF graph/triple structure.
> >
> > In contrast to SKOS, with DCAM, it's not a question of looking at "the
> > world" in a different way. Whether I think of my data as an RDF graph or a
> > DCAM Description Set (or as both, depending on how I'm looking at it!), my
> > "world" is still the same: it has foaf:Persons who author bibo:Documents
> > that are about skos:Concepts that are in skos:ConceptSchemes.
> >
> > Rather with DCAM, I'm looking at the structure of my _data_ in a different
> > way.
> >
> > So I'm afraid I'm struggling to grasp the significance of comparing the
> > DCAM to SKOS - at least at the level that comparison seems to be being
> > applied in these discussions. I understood Andy's mention of SKOS on 05/01
> >
> > https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=DC-ARCHITECTURE;dc1738b9.1201
> > <https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=DC-ARCHITECTURE;dc1738b9.1201>
> >
> > to be about the practical usefulness of SKOS, the fact that it addresses a
> > requirement that people have ("how do I represent my thesaurus using
> > RDF?"), not saying that DCAM was something "similar in nature" to SKOS.
> >
> > Further on in that thread, Kai said on 09/01:
> >
> > https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=DC-ARCHITECTURE;1fc1d387.1201
> > <https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=DC-ARCHITECTURE;1fc1d387.1201>
> >
> > > RDF is not only defined for the representation
> > > of metadata, it is so abstract that at the same time, it allows for
> > instance the
> > > definition of ConceptSchemes in SKOS. And if there is a need for the
> > > definition of a ConceptScheme, I argue that there is a need for the
> > definition
> > > of a DescriptionSet, too.
> >
> > I think this is where I got lost :)
> >
> > (To me), a SKOS Concept Scheme is just another thing in my "world"
> > (alongside a FOAF person etc), another thing to be named with a URI and
> > described in my data, my graph, using RDF triples.
> >
> > But a DCAM Description Set is "a thing in my data", not in my "world".
> > Sure, I could name and describe it (just as I could name and describe an
> > RDF graph or an RDF triple) but my main "use" of the Description Set notion
> > is as a way of structuring my data.
> >
> > So, from my perspective, I can't help feeling that an SKOS Concept Scheme
> > and a DCAM Description Set are very different things, and I'm struggling to
> > grasp why comparing them is useful.
> >
> > I'm not saying it isn't useful, just that, right now, I don't "get it" :)
> >
> > Pete
> >
> > Pete Johnston
> > Technical Researcher
> > Eduserv
> > E: [log in to unmask] <mailto:[log in to unmask]>
> > T: +44 (0)1225 474323 <tel:%2B44%20%280%291225%20474323>
> > F: +44 (0)1225 474301 <tel:%2B44%20%280%291225%20474301>
> > www.eduserv.org.uk <http://www.eduserv.org.uk>
> > Eduserv is a company limited by guarantee (registered in England & Wales,
> > company number: 3763109) and a charity (charity number 1079456), whose
> > registered office is at Royal Mead, Railway Place, Bath, BA1 1SR.
> >
> >
> > > -----Original Message-----
> > > From: DCMI Architecture Forum [mailto: DC- <mailto:DC->
> > > [log in to unmask] <mailto:[log in to unmask]> ] On
> > Behalf Of Thomas Baker
> > > Sent: 26 January 2012 23:31
> > > To: [log in to unmask]
> > <mailto:[log in to unmask]>
> > > Subject: DCAM: the analogy to SKOS
> > >
> > > In yesterday's Provenance Task Group telecon we found ourselves talking
> > > about DCAM [1]. One point of discussion was the analogy of DCAM to SKOS.
> > >
> > > On January 5, Andy had written:
> > >
> > > > So I think the pertinent question that needs to be answered pretty
> > > > early on in the outer layers of Stuart's onion is "why should I invest
> > > > time understanding the DCAM when I could be learning RDF/Linked
> > > Data/whatever instead?".
> > > >
> > > > If we compare the DCAM with, say, SKOS and ask the same kind of
> > > > question the answer is more obvious I think - people need to
> > > > understand both RDF and SKOS because SKOS gives them something useful
> > > > in the area of 'vocabulary' handling that RDF on its own doesn't give
> > them.
> > > >
> > > > The answer for the DCAM is much less clear except in terms of the
> > > > original rationale for having the DCAM at all, i.e.
> > > >
> > > > "It provides an information model which is independent of any
> > > > particular [DCMI] encoding syntax. Such an information model allows us
> > > > to gain a better understanding of the kinds of [DCMI] descriptions
> > > > that we are encoding and facilitates the development of better mappings
> > > and cross-syntax translations"
> > > > ("[DCMI]" additions by me).
> > > >
> > > > which, unfortunately, is a very inward looking (and rather narrow)
> > > > rationale that is unlikely (as history has shown us) to be of much
> > > widespread interest.
> > >
> > > To which Kai had responded:
> > >
> > > > [The] analogy to SKOS is perfect, because that was exactly how I
> > > > started the RDF-based DCAM wiki page yesterday [1].
> > > > Provide DCAM as a model for metadata just like SKOS is for vocabulary
> > > > handling.
> > > >
> > > > [1] http://wiki.dublincore.org/index.php/DCAM_Revision_Tech
> > <http://wiki.dublincore.org/index.php/DCAM_Revision_Tech>
> > >
> > > In yesterday's call, Kai elaborated on the notion of DCAM as an
> > equivalent of
> > > SKOS for metadata. I understood him to say that SKOS is an RDF
> > vocabulary,
> > > but one might also see it as an Abstract Model that could be used by
> > people
> > > who do not care about RDF.
> > >
> > > This reminded me that in the Semantic Web Deployment WG, we did in
> > > effect try to express a high-level "abstract model" for SKOS (a
> > formulation I
> > > actually helped write) [2]:
> > >
> > > Using SKOS, _concepts_ can be identified using URIs, _labeled_ with
> > lexical
> > > strings in one or more natural languages, assigned _notations_
> > (lexical
> > > codes), _documented_ with various types of note, _linked to other
> > > concepts_
> > > and organized into informal hierarchies and association networks,
> > > aggregated into _concept schemes_, grouped into labeled and/or
> > ordered
> > > _collections_, and _mapped_ to concepts in other schemes.
> > >
> > > ...summarizing the essence of SKOS in just one sentence. Arguably, this
> > is
> > > the sort of formulation -- one which does not itself even mention RDF but
> > > which maps to RDF in the specification -- we could aspire to make for
> > DCAM.
> > >
> > > I cannot readily formulate one sentence that summarizes what I think DCAM
> > > can offer, though it would perhaps be interesting to try. The story I
> > have in
> > > mind for DCAM might say that metadata uses items of information --
> > strings
> > > and URIs, perhaps belonging to sets of strings or URIs (i.e., syntax or
> > > vocabulary encoding schemes) -- to describe (make statements about)
> > things
> > > of interest; that it groups these items into Descriptions about one
> > particular
> > > thing of interest and groups related Descriptions into Description Sets,
> > which
> > > are often instantiated in implementations as "records".
> > >
> > > How these items are used to make meaningful "statements" about things
> > > would be the part that one inherits from RDF. DCAM, as I see it, can
> > provide
> > > an "interface" to underlying (meaningful) statements by specifying
> > patterns
> > > of information items grouped into Descriptions and Description Sets.
> > >
> > > If that is what DCAM is, or should be, then I wonder whether we can
> > specify
> > > those patterns in enough detail to be useful as an interface to triples
> > without
> > > becoming too complicated. In 2007-2008, for example, it seemed
> > reasonable
> > > to translate "DCAM statements" about value resources using RDF statements
> > > with rdf:value and literals or RDF statements with dcam:memberOf and
> > > vocabulary encoding scheme URIs [3]. From the perspective of best
> > practice,
> > > that looks like an oversimplification. Today, one might want to consider
> > using
> > > various other properties in statements about a value resource --
> > rdfs:label,
> > > skos:prefLabel, skos:notation, foaf:name, or dcterms:title... -- though
> > > perhaps _not_ rdf:value [4]. Can a DCAM still be defined as an interface
> > to
> > > triples as straightforward as [4], or would it need to evolve in the
> > direction of
> > > a more complex and differentiated set of patterns?
> > >
> > > For discussion on Monday's call (at 11:00 EST)...
> > >
> > > Tom
> > >
> > > [1] http://wiki.bib.uni-mannheim.de/dc-
> > <http://wiki.bib.uni-mannheim.de/dc->
> > > provenance/doku.php?id=minutes_2012_01_15
> > > [2] http://www.w3.org/TR/skos-reference/
> > <http://www.w3.org/TR/skos-reference/>
> > > [3] http://dublincore.org/documents/dc-rdf/#sect-4
> > <http://dublincore.org/documents/dc-rdf/#sect-4>
> > > [4] http://www.w3.org/2011/rdf-wg/track/issues/27
> > <http://www.w3.org/2011/rdf-wg/track/issues/27>
> > >
> > > --
> > > Tom Baker < [log in to unmask] <mailto:[log in to unmask]> >
> >
>
>
>
> --
> Bernard Vatant
> Vocabularies & Data Engineering
> Tel : + 33 (0)9 71 48 84 59
> Skype : bernard.vatant
> Linked Open Vocabularies <http://labs.mondeca.com/dataset/lov>
> --------------------------------------------------------
>
> Mondeca
> 3 cité Nollez 75018 Paris, France
> www.mondeca.com <http://www.mondeca.com/>
>
> Follow us on Twitter : @mondecanews <http://twitter.com/#%21/mondecanews>
>
>
>