 |
 |
Hi Antoine, first a minor point: dcam:Description is already removed as RDF class, that was wrong in the first draft. dcam:DescriptionSet as a class would be subclass of rdf11:Graph, or however the RDF working group will call a graph (hopefully there will be a class to identify graphs...) Having said that, I think we are really on the same line here. A DescriptionSet is a (named) graph and not an artifical additional layer, that is introduced. And my main motivation to introduce dcam:DescriptionSet as a class is that I can talk about DescriptionSets and create statements with a DescriptionSet as a subject, this is a requirement for metadata provenance. This is in line with best practices in RDF, and it makes IMHO things clearer for people who are not deeply involved with RDF. Noone will be forced to use DescriptionSets generally, there is no notion that a Dublin Core statement has to be part of a DescriptionSet. But it can. Admittedly, this does only make full sense with the upcoming RDF version. Without a proper notion of a named graph in RDF, we could still introduce these classes, but there would remain a gap that is only bridged by best-practice, i.e. that we provide statements under an URL and just say that "URL a dcam:DescriptionSet". Cheers, Kai Am 04.03.2012 23:33, schrieb Antoine Isaac: > Kai, others, > > To try to bridge with the other thread for, my point (2) below would not > imply that there should not be any DCAM notion of Description. Just that > it may not be needed as an RDF vocabulary element. > DCAM could just introduce some "human-readable form" of the notion and > then say how descriptions are done in RDF (akin to a best practice). > Without using a new RDF class dcam:Description. In fact even if we need > some reification, I guess we would also re-use what RDF gives > "natively", be it named graphs or whatever RDF2 offers us. But I trust > we're on quite a similar line here. > > I'm curious to hear whether this matches Jeff's idea of "DCAM (as a > pseudo domain model?) would factor out". I think indeed that in an RDF > implementation of DCAM description (and other DCAM notions), DCAM should > be as transparent as possible. Namely, just provides rules on how to do > things. > (and indeed it may be more difficult to have the same situation for DSP, > because of the open vs closed-world issue. But that's another story ;-) ) > > Antoine > > >> Hi Kai, >> >> OK, I'll try to put something on the page (maybe with Tom's help ;-) ) >> >> And yes, to me representing "explicitly" DCAM in RDF is a bit akin to >> RDFS in RDFS, or RDF in RDF (aka RDF reification)... >> >> I do agree that DCAM may be based on RDF. But I think one does not >> really need an RDF vocabulary for DCAM. >> >> Consider one wants to represent a DCAM description in RDF, say for a >> book. One can: >> >> (1) use a DCAM vocabulary that has a class dcam:Description, create an >> instance of that class, and relate this instance to every statements >> (subject, predicate, object) that this description should "contain" >> for the book (creator, publisher, etc) >> >> (2) just use RDF to assert statements directly for the book, without >> bothering about representing any "meta" info in the RDF data. >> >> As said, I see some value in scenario (1), but I think it does not fit >> the majority of use cases. >> >> Cheers, >> >> Antoine >> >> >>> Hi Antoine, >>> >>> feel free to add such a section to the wiki page, of course I don't >>> want to have people discouraged or disappointed by reading this page >>> in this early, draftish state. >>> >>> I don't think that DCAM in RDF is like RDFS in RDFS. In fact, since >>> last week when we had a look at DC-RDF and DCAM, I am even more >>> convinced that DCAM is already based in RDF and we just should go the >>> last step to make this clear. Interesting for me was also the link >>> that was mentioned in the last call by Corey [1] (from the minutes, I >>> did not attend). This really looks like DCAM would be based on RDF, >>> isn't it? >>> >>> Cheers, >>> >>> Kai >>> >>> [1] >>> http://dublincore.org/documents/2008/01/14/singapore-framework/singapore-framework.png >>> >>> >>> Am 04.03.2012 17:26, schrieb Antoine Isaac: >>>> Hi Kai, >>>> >>>> That is interesting. There's still something that makes me wondering >>>> about these DC-in-RDF efforts though: is the idea really to have >>>> DCAM as >>>> an RDF vocabulary, on the same level as SKOS and others? >>>> >>>> I see the intellectual value of it, but that remind me a bit about some >>>> exercises I've seen of representing, say, RDFS in RDFS (pointers >>>> must be >>>> findable, but it's no use bothering everyone with that now). It seems >>>> quite artificial, and not really needed. >>>> >>>> In fact to be fair I can see some real value, when one wants to >>>> reify DC >>>> descriptions & statements: it's probably a valid use case, >>>> especially in >>>> the provenance context. Just like reification in RDF: rdf:Statement, >>>> rdf:subject, etc... >>>> But (and maybe it's a better re-phrasing of my criticism above) it >>>> could >>>> be confusing to focus readers' attention to this now. >>>> Is it worth putting a bit caveat or "scope of the document"section in >>>> front of that wiki page? >>>> >>>> Cheers, >>>> >>>> Antoine >>>> >>>> >>>>> Hi all, >>>>> >>>>> I just updated the wiki page with the results of a brainstroming >>>>> session in Dagstuhl[1] last week: >>>>> >>>>> http://wiki.dublincore.org/index.php/DCAM_Revision_Tech >>>>> >>>>> I merged in the contents of DC-RDF to see if we hit on any conflicts. >>>>> So far it seems to work. The document is a little messy, sorry for >>>>> that. I hope I find the time to clean it up and of course work further >>>>> on it this week. >>>>> >>>>> Main change: The graph container is now the description set, >>>>> descriptions would not be a class in RDF, they are only implicitely >>>>> defined based on the notion of statements with the same subject. >>>>> >>>>> Interesting question: What happens to the record? Again this seems to >>>>> be a question that relates to similar questions in the RDF community: >>>>> How to distinguish the content from the serialization. It would be >>>>> interesting to keep it somehow, but maybe it will belong rather to >>>>> best-practice than to DCAM. >>>>> >>>>> On a side note, I would like to mention that we started in Dagstuhl >>>>> with a mapping between DC-Terms and the upcoming PROV ontology [2]. >>>>> This will be discussed on the DCPROV mailinglist and is a joint effort >>>>> between the DCMI Metadata Provenance TG and the W3C Provenance Working >>>>> Group. >>>>> >>>>> Cheers, >>>>> >>>>> Kai >>>>> >>>>> [1] >>>>> http://www.dagstuhl.de/no_cache/en/program/calendar/semhp/?semnr=12091 >>>>> [2] http://www.w3.org/2011/prov/wiki/ProvDCMapping >>>>> >>>> >>> >> > -- Kai Eckert Universitätsbibliothek Mannheim Stellv. Leiter Abteilung Digitale Bibliotheksdienste Schloss Schneckenhof West / 68131 Mannheim Tel. 0621/181-2946 Fax 0621/181-2918