Re: dc review

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
>>>
>>
>>
>>
>
>