Re: dc review

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
>