Re: dc review

Hi Tim,
I have pushed your suggested edits. Thanks again for your exhaustive review.
Concerning the clarification before the tables, I have added the following
sentence:
Regarding the classes, it is important to note that when a class is found
to be defined as the range of some DC property that does not describe the
provenance of a resource (but its descriptive metadata), it has been left
out of the mapping rather than adding it as a subclass of prov:Entity(e.g.,
dct:MediaType, dct:Standard).

I am a bit tired now, so If you want to suggest anything better, feel free
to ellaborate and I'll update it.
Best,
Daniel


2013/4/19 Daniel Garijo <dgarijo@delicias.dia.fi.upm.es>

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