Re: Roles Proposals

 I will use same reasoning as Jacob, but different weights:

On 24 August 2015 at 14:46, Jacob Jett <jjett2@illinois.edu> wrote:

>> * 3.2.1 Require the use of SpecificResource for Bodies
> +0.5 -- What does this do to the multiplicity body types (e.g., choice,
> composite, etc.)? Are you also proposing to absorb those into the
> SpecificResource as sub-classes? Are we left with a nesting set of
> SpecificResources? The text of the proposal is unclear. I'm also not certain
> that we've considered how this change propagates through various bits and
> pieces of the model.

-1: Same concerns as Jacob.


>> * 3.2.2 Require the use of SpecificResource for Targets
> +0.5 -- Same concern as above.

-1


>> * 3.2.3 Allow hasRole on new EmbeddedTextualBody class>

+0

I guess here you mean also to allow using EmbeddedTextualBody directly
as a hasBody (and hasTarget?) - otherwise there would not be much
point.


Ontology-wise I would then hope for a common superclass of
EmbeddedTextualBody and SpecificResource to be the domain of hasRole -
rather than having to use an anonymous union-class. Could this class
then be the range of hasBody (and hasTarget)?

Would an EmbeddedTextualBody be a subclass of SpecificResource? That
could get weird.

Introducing class hierarchies is not particularly compatible with the
typing-free vision - as you would then have to dispatch on various
subclass-specific properties  to know what is meant. (or turn on your
OWL reasoner - but it would fall over due to that literal-punned
hasBody)

So if this gets included, then @type:SpecificResource  (or
type:SpecificResource) would have to stay as well.


>> * 3.2.4 Rename hasSource to hasContent

> -1 -- I'm still trying to wrap my head around this one. Is our intent to say
> that bodies and targets are content containers (i.e., little more than
> objects)? Is that a different implication than what was implied by hasSource
> (i.e., this thing was derived from this other thing)? I feel like things
> only get weirder as you layer on other features like selectors. For
> instance, we have a specific resource which is scoped and defined by a set
> of selectors and then we say it "hasContent" and by that we mean the
> resource from which the SpecificResource was selected from. The semantics
> are very odd. If folks don't like hasSource, I'd suggest using something
> like 'derivedFrom' or anything else that suggests that my specially selected
> sub-portion of a resource is not, in fact, the content of the whole
> resource.

-1 for the very same reasons.


>> * 3.2.5 Remove motivatedBy completely, rename Motivation to Role
> +1

+1




-- 
Stian Soiland-Reyes, eScience Lab
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/    http://orcid.org/0000-0001-9842-9718

Received on Monday, 24 August 2015 14:18:49 UTC