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 > > > > > > > > >