Re: Multiplicity and Roles

Inline below.

On Tue, Aug 25, 2015 at 6:25 PM, Timothy Cole <t-cole3@illinois.edu> wrote:

> Embedded below.
>
>
>
> *From:* jgjett@gmail.com [mailto:jgjett@gmail.com] *On Behalf Of *Jacob
> Jett
> *Sent:* Tuesday, August 25, 2015 4:32 PM
> *To:* Cole, Timothy W <t-cole3@illinois.edu>
> *Cc:* Benjamin Young <bigbluehat@hypothes.is>; Robert Sanderson <
> azaroth42@gmail.com>; Ivan Herman <ivan@w3.org>; W3C Public Annotation
> List <public-annotation@w3.org>
> *Subject:* Re: Multiplicity and Roles
>
>
>
> Hi Tim,
>
>
>
> I agree with the substance of what you're saying, although I'm missing
> your point about 'canonical exemplar' being contextual.
>
>
>
> Arguably canonical exemplar is contextual information that some might want
> to say is particular to an annotation, and therefore (I was trying to say)
> your example where you want to express that a particular item in a set is
> the canonical exemplar is a better argument for using role on an item or
> member than the control dataset example. Though I still think it falls
> short.
>

I'm still not following. The juxtaposition (and therefore the Composite
entity) is particular to the annotation. Any role information is particular
to that Composite which is particular to that annotation. But I might be
imagining Roles as being overly equivalent to other kinds of specifiers.

<snip>


>
>
> The model includes examples of instances of oa:SpecificResource as bodies
> and targets.  It does not actually show examples of SpecificResource in any
> other context, but I think you are correct to the extent that an instance
> of oa:SpecificResource can appear as an item or member in Choice, Composite
> or List, when the Choice, Composite or List is a body or target. We
> probably need to clarify this within the model. While multiplicity classes
> can be used in other contexts, e.g., when a choice of selectors is
> available, I don't believe an instance of oa:SpecificResource is allowed as
> a member of an instance of oa:Choice used to list alternative selectors,
> but I'm not sure.  This gets pretty abstract… Am I forgetting a use case?
> Can a selector be a SpecificResource?
>
>
+1 for clarifying. My thinking was that since the text in 5 states that the
object of oa:members may be any resource except for simple string literals
(where "the embedded textual body resource pattern MUST be used"), then
there is nothing which would prevent Specific Resources from being used as
the objects of oa:members predicates except a rather conservative reading
of the Specific Resource taking the role of Body or Target in 4.1.

I'm pretty confident that a Specific Resource can't be a Selector because
Selectors never appear in the role of Body or Target but, the objects of
oa:members do when the object of hasBody / hasTarget is a Choice, Composite
or List (or at least that's my friendly interpretation). A less friendly
interpretation appeared at Balisage a couple of years back (
http://www.balisage.net/Proceedings/vol10/html/Dubin01/BalisageVol10-Dubin01.html
).


>
>
> My point is that since the members of the multiplicity types are allowed
> to be SpecificResources we'll be leaving the door open for some amount of
> "tag abuse" since hasRole is a property that all SpecificResources may
> have.
>
>
>
> I don't think the proposal means to assert that all instances of
> SpecificResource can have hasRole, again the introduction is pretty clear
> we are talking about the role of annotation bodies and targets, but I may
> be wrong. Or maybe we need to be clearer about this.
>
>
>

It's hard to say. Typically though I wouldn't want an entity to have
properties that are contingent on its role. Those sound like properties of
the role and not the entity. (Basically entailing the sub-class solution to
capture the subtle difference between the body/target roles and the members
role.)

Administrative: In the existing draft, Specific Resources are defined in 4.
It seems likely we'd need to boot that up to 3 to support proposals 3.2.1
and 3.2.2.


> <snip>
>
>
>
> The model says that oa:Choice is in construction equivalent to rdf:Alt,
> oa:Composite is in construction equivalent to rdf:Bag, and oa:List is a
> subclass of oa:Composite.  None of them actually depend or try to replicate
> rdf:List or rdf:Collection for the reasons you suggest.  But they are not
> exactly equivalent in meaning rdf:Bag and rdf:Alt.  In the model as
> currently written we introduce order for oa:Choice and oa:List (as
> indicated by the predicate oa:member).  oa:Composite is explicitly
> unordered according to the model. From an RDF standpoint the claim that
> Choice and List are ordered is very tenuous (at best).
>
>
>

Actually the verbage in 5.1 bakes orderedness right into oa:Choice along
with the fact that the order is given by it's (presumably) one and only
member, a rdf:List. Unfortunately 5.3 (List) also claims to be a construct
that provides order. I don't know that we actually have an unordered list
except in the tacit form of multiple bodies. However, it's really unclear
how 5.1 and 5.3 differ beyond the use of rdf:List to apply order in 5.1 and
its absence in 5.3. In fact, I'm tempted to call 5.3 redundant except that
its members not equivalent to one another. Why it doesn't also use rdf:List
to apply order? If rdf:List isn't necessary then why specify it in 5.1?

Perhaps we should put section 5 (or specifically these Choice / List
things) on the agenda for an upcoming call, perhaps one of the ones in
September / October?

<snip>

>
>
> I completely agree that data models do have contextual constraints but
> that's not the way that Specific Resource or the Specifier and Multiplicity
> sections of the model are written right now and nothing in the proposal
> text that we have to date changes that. I think the cost for limiting the
> scope of Role to only SpecificResources that are the objects of hasBody and
> hasTarget is too high. We'd need a new sub-type of SpecificResource that
> didn't have Role as a property that could be used for Choice, Composite,
> and List and with all of the other Specifiers (in my mind hasRole is just
> another kind of specifier, specifying context in this case) or we'd need to
> radically rewrite the Specifier and Multiplicity sections all over again.
>
>
>
> This goes back to making sure we know where oa:SpecificResource is allowed
> now. As I understand it, but Rob or Paolo can correct me, instances of
> oa:SpecificResource are allowed directly as an annotation bodies and
> targets and indirectly as items or members of Choice, Composite and List
> instances that are bodies or targets (or nested within Choice, Composite or
> List instances that are bodies are targets). They are not allowed
> elsewhere. It does get more complicated if they are allowed elsewhere.
> Whether we need a subclass of SpecificResource to make clear where hasRole
> can appear and where it can't may be worth a discussion. I hope not, but
> even if we do it'll be in the model only (I think), not in the JSON
> serialization.
>
>
>

Agree!


> If we go with SpecificResource only appears as body / target or as
> member/item in multiplicity class instances appearing as body/target, then
> one question becomes whether it is a good idea to limit oa:hasRole to
> instances of oa:SpecificResource that appear directly as annotation bodies
> and targets (i.e., not allow them on SpecificResources appearing in item or
> member lists).  That would solve a great deal of what's being discussed
> here, I think. Whether it would require defining a subclass to clarify this
> distinction is another matter.
>
>
>
> The second question becomes whether oa:hasRole is a valid property for
> Choice, Composite or List instances appearing directly as annotation bodies
> and targets. Alternatively, if you constrain oa:hasRole to
> oa:SpecificResource, then if you want to associate a role with a Choice,
> Composite or List, you have to do so by instantiating a SpecificResource
> that has as source/content the Choice, Composite or List.
>
>
>
> I think the latter question especially is still open. Every time we get
> close, there's always one more thing…
>

Yeah, that's why I was saying this is was a slippery slope months ago. :/

I think we're pretty close to getting the role thing resolved but we'll
probably have to totally rehash 5.1 and 5.3 anyway because it's not clear
to me that we really want to be using rdf:List to apply order in 5.1 and
I'm simply unclear on how 5.3 proposes to apply order at all beyond the
arbitrary first in - first out kind of stack of strings/things.

Regards,

Jacob


_____________________________________________________
Jacob Jett
Research Assistant
Center for Informatics Research in Science and Scholarship
The Graduate School of Library and Information Science
University of Illinois at Urbana-Champaign
501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
(217) 244-2164
jjett2@illinois.edu


<snip old stuff>