- From: Tobias Bürger <tobias.buerger@sti2.at>
- Date: Wed, 18 Mar 2009 13:50:01 +0100
- To: Pierre-Antoine Champin <pchampin@liris.cnrs.fr>
- CC: public-media-annotation@w3.org
Dear Pierre-Antoine, thank you first of all for your comments. Answers are inline. Pierre-Antoine Champin schrieb: > Hi, > > sorry as well for being absent yesterday without prior notification. > > A few comments: > > 1/ I do not agree about the mapping between xmp:CreatorTool (a *tool*) > and dc:creator (an *agent*). > We had a discussion about this actually, too. The official defintion of dc:creator is "Examples of a Creator include a person, an organization, or a service. Typically, the name of a Creator should be used to indicate the entity." [2] So a creator can be a service. It is debateble if this includes a tool, too. > 2/ each XMP has two rdfs:comment's, and a skos:closeMatch, although it > seems to me that the second rdfs:comment should apply to the *target* of > the skos:closeMatch. For example, the first description should look like: > > <rdf:Description rdf:about="http://wwwns.adobe.com/xmp/1.0/CreateDate"> > <rdfs:comment>The date and time the resource was originally > created.</rdfs:comment> > <skos:closeMatch> > <rdf:Description rdf:about="http://purl.org/dc/elements/1.1/date"/> > <rdfs:comment>A point or period of time associated with an > event in the lifecycle of the resource.</rdfs:comment> > </rdf:Description> > </skos:closeMatch> > </rdf:Description> > > or in N3 > xmp:CreateDate > rdfs:comment "The date and time the resource was originally created." ; > skos:closeMatch dc:date . > > dc:date rdfs:comment "A point or period of time associated with an > event in the lifecycle of the resource." . > You are right, the second comment should apply to the target of th skos:closeMatch. Best, Tobias > > pa > > Tobias Bürger a écrit : > >> Dear all, >> >> Veronique and myself have our first toy example ready to demonstrate how >> the mapping of properties could work using semantics. The example maps >> properties from Dublin Core [2] to XMP [4]. >> >> We see 4 different solutions on how we could approach this mapping: >> >> (1) The first option is to use SKOS mappings [1]. The problem with this >> option is, that SKOS mappings were being conceived to hold between SKOS >> concepts and not properties. So we would use the mapping vocabulary in >> a semantically incorrect way (from the point of the SKOS specification >> and the inference engines trying to make sense of it). >> >> (2) The second option is to use owl:equivalentProperty / owl:sameAs >> which we can not consider given the different semantics of the >> properties defined in the different formats >> >> (3) The third option is to subProperty all the properties from the >> formats to e.g. Dublin Core [2], Dublin Core Terms [3] or any other >> format which is generic enough. >> >> (4) The fourth option is to create our own authoritative schema which >> consolidates all the formats we are looking at and to which the other >> formats can be mapped to. >> >> Veronique has prepared a small example using the first option which >> matches from the DC properties from [2] to XMP properties from [4]. >> Please find the example attached (XMPtoDCskosMapping.rdf). The XMP >> properties came from the XMP example document which is also attached >> (xmpexample.xml). >> >> We are curious to hear your opinion on the options above and our toy >> example. >> >> Best regards, >> >> Tobias & Veronique >> >> >> [1] http://www.w3.org/TR/skos-reference/#mapping >> [2] http://dublincore.org/documents/dces/ >> [3] http://dublincore.org/documents/dcmi-terms/ >> [4] http://www.exiv2.org/tags-xmp-xmpMM.html >> >> > > -- _________________________________________________ Dipl.-Inf. Univ. Tobias Bürger STI Innsbruck University of Innsbruck, Austria http://www.sti-innsbruck.at/ tobias.buerger@sti2.at __________________________________________________
Received on Wednesday, 18 March 2009 12:49:06 UTC