 |
 |
Jane, I agree that "RDF is but one way". I routinely use UML class diagrams when I'm trying to sort out a conceptual model, both on my own and when I'm working with domain experts. Somehow seeing the domain expert's jargon packaged as bits of graphics and populated with use case-based sample instance data makes reality clearer for everyone. When the model stabilizes, converting the graphical UML classes, attributes, and associations into OWL classes, datatype properties, and objecttype properties is a trivial task. Converting the sample instance data into OWL-compliant RDF is just as easy. There are some bells and whistles in both paradigms that don't map easily (e.g. rdfs:subPropertyOf), but if the person doing the conversion knows the limitations, it's not a big problem. Jeff > -----Original Message----- > From: DCMI Architecture Forum [mailto:[log in to unmask]] > On Behalf Of Greenberg, Jane > Sent: Sunday, March 04, 2012 3:40 PM > To: [log in to unmask] > Subject: Re: DCAM RDF Revision revisited > > My sense all along is that the DCAM doesn't need to be presented in- > and-only RDF. Perhaps I'm wrong (?). It is conceptual. RDF is but > one way. > > I like Karen's question, and believe it is important for DCMI to have a > collectively agreed upon understanding here. It is fundamental for > moving forward effectively. the DCAM has been really important for me > as a teaching tool, in providing students with guidance to think about > representation (or, dare I say bibliographic description) outside a > box, and in a new, emerging way. > > I'd like to contribute more to this current discussion than I can at > the moment, and greatly appreciate what's being discussed here. > > Thnx all - jane > > > -----Original Message----- > From: DCMI Architecture Forum [mailto:[log in to unmask]] > On Behalf Of Young,Jeff (OR) > Sent: Sunday, March 04, 2012 9:03 PM > To: [log in to unmask] > Subject: Re: DCAM RDF Revision revisited > > Corey, > > I agree there are other existing solutions, as you suggest. It's not > clear to me, though, why OWL has a bad reputation for human > readability. Take Schema.org as an example of how lightweight an > RDFS/OWL model could possibly be represented and understood. > > It might also be interesting to flip the problem on its head. Rather > than imaging how OWL could be used to *prescribe* the model used to > construct a graph, imagine it being used *describe* the graphs that > someone wants to publish. Combine this with VoID, and the picture of > any given dataset could be fairly complete. This descriptive approach > would allow graph models to develop organically just like the terms > defined in ontologies are. > > Just some ideas. > > Jeff > > > -----Original Message----- > > From: DCMI Architecture Forum [mailto:[log in to unmask]] > > On Behalf Of Corey A Harper > > Sent: Sunday, March 04, 2012 2:48 PM > > To: [log in to unmask] > > Subject: Re: DCAM RDF Revision revisited > > > > Hi Jeff, > > > > I definitely think that what you're proposing is one valid technical > > approach to meeting these needs. I don't think it's the only way. I'm > > still wrapping my head around this notion of Pellet using OWL for > > closed-world validation rather than open-world inferencing, but I > like > > the idea. I also think that XSD, Relax-NG, Schematron, etc offer > > suitable technical drafts. > > > > My sense of the value of a revised DCA* / DCDSP specification set is > > to provide more human readable documentation about how to go about > > doing so, and indeed, why one would even want to. > > > > Perhaps that's not as much the group's sense of what's needed, > though. > > > > -Corey > > > > On Sun, Mar 4, 2012 at 2:32 PM, Young,Jeff (OR) <[log in to unmask]> > > wrote: > > > Sorry I don't have time to explore what is being proposed, but I > > suspect > > > that the graph (aka "record") boundaries could be "defined" by > > > publishing an OWL ontology that documents the classes, properties, > > and > > > cardinality constraints that are expected to be contained within > it. > > > Perhaps I've misinterpreted the difference between DCAP and DCAM, > > > but > > my > > > impression is that this OWL solution would serve for DCAP and that > > DCAM > > > (as a pseudo domain model?) would factor out. > > > > > > Jeff > > > > > >> -----Original Message----- > > >> From: DCMI Architecture Forum [mailto:DC- > > [log in to unmask]] > > >> On Behalf Of URBAN, RICHARD > > >> Sent: Sunday, March 04, 2012 1:53 PM > > >> To: [log in to unmask] > > >> Subject: Re: DCAM RDF Revision revisited > > >> > > >> Hi Karen, > > >> > > >> Some of that will be addressed by the interoperability section > > >> I'll > > > be > > >> working on (see my earlier e-mail). According to that document, > > > W3C > > >> semantic web standards are a level of interoperability that is > > outside > > >> DCAM, and that DCAM is solely concerned with syntactic > > >> interoperability. However, I'd argue that DCAM has been > > >> influenced > > > by > > >> the syntactic requirements entailed by the formal semantics that > > >> W3C has recommended. (and at the moment is not agnostic of them). > > > >> To > > me > > >> Kai's work makes those connections explicit in a useful way, even > > >> if individual application environments are not interested in what > > >> those semantics have to offer. (I'm still trying to get my head > > >> around how DCAM would be agnostic of any of this....) > > >> > > >> I do think that one of the things that DCAM needs to do is to map > > our > > >> intuitive sense of "records" onto those semantics. > Unfortunately, > > I > > >> think that these kinds of records (an instantiation of a > > >> DescriptionSet) crosses some boundaries equivalent to the > > >> Work->item relationships in FRBR that makes it especially > confusing > > >> topic. (it may be more appropriate for the DCAM for Librarians, > > >> rather than > > Kai's > > >> technical treatment). > > >> > > >> Richard > > >> > > >> > > >> On Mar 4, 2012, at 11:51 AM, Karen Coyle wrote: > > >> > > >> > Can someone summarize what DCAM provides that is not provided by > > W3C > > >> semantic web standards? A statement of that nature would be a good > > >> addition to the page. > > >> > > > >> > Also, I notice that the page does not have any mention of syntax > > >> encoding scheme -- is this structure no longer included or is it > > just > > >> not yet on this page? > > >> > > > >> > kc > > >> > > > >> > On 3/4/12 8:38 AM, Kai Eckert wrote: > > >> >> 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 > > >> >>>> > > >> >>> > > >> >> > > >> > > > >> > -- > > >> > Karen Coyle > > >> > [log in to unmask] http://kcoyle.net > > >> > ph: 1-510-540-7596 > > >> > m: 1-510-435-8234 > > >> > skype: kcoylenet > > >> > > > > > > > > > -- > > Corey A Harper > > Metadata Services Librarian > > New York University Libraries > > 20 Cooper Square, 3rd Floor > > New York, NY 10003-7112 > > 212.998.2479 > > [log in to unmask]