- From: Daniel Garijo <dgarijo@delicias.dia.fi.upm.es>
- Date: Fri, 19 Apr 2013 18:00:36 +0200
- To: Timothy Lebo <lebot@rpi.edu>
- Cc: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>, Provenance Working Group <public-prov-wg@w3.org>
- Message-ID: <CAExK0De_ByKEXL6P8d4FRkRRAcUkZo-VQDXNVTQm-6GipBirPw@mail.gmail.com>
Ok, I will add some extra explanation on the classes table. Thanks, Daniel 2013/4/19 Timothy Lebo <lebot@rpi.edu> > Daniel, > > On Apr 19, 2013, at 11:53 AM, Daniel Garijo < > dgarijo@delicias.dia.fi.upm.es> wrote: > > Tim, > The focus of the mapping was to map those terms that had to do with the > provenance of a resource. > Most of the classes are introduced to be the range of a property to > describe the metadata of a resource. > Our train of thought doing the mapping has been: Ok, if this class is the > range of some dct:property that does not > affect the provenance of the resource (being descriptive metadata such as > the standard used, or the media type), > then we have left it out of the mapping. The thing is that if the media > type, etc. has its provenance described > (with dct:creator for example), then it will be mapped as an entity > anyway. > > > I totally agree, and I like how you describe the approach above. > But this was not described in the document. I think something like it > should go before your exclusion tables. > > > Otherwise it's like saying that all are owl:Things > (prov:Entity) and that's it, which is not useful. > > Regarding the semantics, I think (and I would have to check it) that the > Dublin Core Abstract Model was created before > RDF specifications. Then They provided a mapping to RDF (the terms). > > > Beyond my experience, no worries. > > Thanks, > Tim > > > > Best, > Dani > > > 2013/4/19 Timothy Lebo <lebot@rpi.edu> > >> Daniel, >> >> (in full recognition that my absence in these reviews warrants any and >> all disregard for my comments) >> >> >> On Apr 19, 2013, at 11:29 AM, Daniel Garijo < >> dgarijo@delicias.dia.fi.upm.es> wrote: >> >> Hi, >> by "not described by any of the DC properties" we meant that is not the >> subject of the description. >> They are declared as the range of those properties you have posted. >> >> >> 1) DC classes are resources, so *could* be described with DC properties. >> (But that's an odd subject to be discussing) >> 2) Why is it that DC properties are within scope of consideration for the >> mapping, but not Classes? You seem to have some weird implicit rule that >> only things described with DC properties may be in the mapping. Why are the >> classes considered first class citizens that are independently worthy of >> being mapped? >> >> >> And in some cases they >> are just literals. >> >> >> outside of RDFS, that does not matter. Even literals are instances of >> classes. No biggie. >> >> To tell you the truth, I am not sure if the Classes are used that much… >> >> >> Fine, but as I mentioned in another comment, un-empirical guesses at >> frequency of use for an existing standard is not a very solid way to write >> a mapping. >> >> >> I don't know the reason why MediaType is a Class and not Title, for >> example. >> >> >> Good point. I may be wrong, but is it because DC doesn't have a clear >> semantics? ::runs away:: >> >> Regards, >> Tim >> >> >> Best, >> Daniel >> >> >> 2013/4/19 Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk> >> >>> On Fri, Apr 19, 2013 at 3:04 PM, Timothy Lebo <lebot@rpi.edu> wrote: >>> >>> >>> >>> > DC definition is "Date (often a range) of validity of a resource." and >>> could correspond to PROV's generation and invalidation of the resource or >>> one of its specializations. >>> > Please acknowledge this relation and provide a stronger justification >>> for why it wasn't' included. >>> >>> The justification could touch on how dct:valid is also used for >>> indicating future/theoritical/planned validation periods or >>> invalidation periods; meanwhile prov:generatedAt and >>> prov:invalidatedAt indicate actual availability. >>> >>> The other point is that the actual syntax of dct:valid is any literal >>> ("For one forthnight"), and rather than using ISO 8601 formats for >>> periods and durations, a variety of actual syntaxes would be found in >>> the wild; therefore it would not syntactically be mappable to either >>> of the properties (which require xsd:dateTime). >>> >>> >>> > DC definition: "Examples of Agent Class include groups seen as >>> classes, such as students, women, charities, lecturers." >>> > dct:AgentClass is a subclass of prov:Organization, specifically those >>> that are viewed as "an educational audience". >>> >>> I'm not sure.. a possible dct:Agentclass could be >>> ex:HighSchoolStudents - not the organization of 'students at Super >>> Duper High School'. The AgentClass instances are used with >>> dct:educationLevel. >>> >>> >>> > Format of a digital resource. This class is not described by any of >>> the DC properties and normally is directly associated to literals (such as >>> ".doc", "jpg", etc.). Therefore it is not part of this mapping. >>> > >>> > "This class is not described by any of the DC properties "? >>> > * What about http://purl.org/dc/terms/format ? It's range is >>> http://purl.org/dc/terms/MediaTypeOrExtent and >>> http://purl.org/dc/terms/FileFormat is narrower than >>> http://purl.org/dc/terms/MediaType >>> > "normally is directly associated to literals (such as ".doc", "jpg", >>> etc.)" >>> > * Under what definition of "normal"? >>> > * Whey are you making claims beyond the DC definition? >>> >>> Agreed, those statements should be dropped. Here's an example of >>> describing a file format with dcterms (This is very secret stuff that >>> nobody does consistently): >>> >>> https://gist.github.com/stain/4635250 >>> >>> >>> >>> >>> > same objections on the rows for MediaType and MediaTypeOrExtent and >>> PhysicalMedium >>> >>> I think it's not interesting to talk about such classifications as an >>> entity. What thing in the world is "text/html"? Would the provenance >>> of that media type be interesting? Most of the time - from a >>> document's point of view - no. (But: For documents made in media >>> types that themselves are evolving, yes!) >>> >>> >>> >>> -- >>> Stian Soiland-Reyes, myGrid team >>> School of Computer Science >>> The University of Manchester >>> >> >> >> > >
Received on Friday, 19 April 2013 16:01:03 UTC