Ladies and Gentlemen…
I believe we have our initial set of testable requirements/use cases.
Jon
I check email just a couple of times daily; to reach me sooner, click here:
http://awayfind.com/jonphipps
On Thu, Feb 2, 2012 at 9:58 AM, [log in to unmask] <
[log in to unmask]> wrote:
> 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
> >
> >
> >
> >
>
