Re: Specific Resource Semantics

On 1/30/13 7:30 PM, Robert Sanderson wrote:
> This is somewhat a semantics argument, but one that is important to
> get right.  It derives from Antoine and Stian's questions about the
> definition of Specific Resources, Specifiers and the "workflow"
> diagram (3.1.1)
>
>
> The question is which relationships and properties *define* the nature
> of the Specific Resource, and which are just informational or
> contextual (if any).
> The spec at the moment treats Style and Scope as annotation specific
> information about the specific resource, but they somehow don't define
> it.
>
> This leads to an issue with the global nature of triples, as if you
> reuse the specific resource, then it still inherits the scope and
> style. As the second annotation to use the specific resource would get
> the scope and style, they seem to be defining properties, not specific
> to the annotation.  This brought up Antoine's comments about ORE
> Proxies, for example.
>
> Secondly, if scope and style do not define the nature of a specific
> resource, then you should not need to create multiple specific
> resources with the same State and Selector, just to have two targets
> which are about the same segment with two different scopes or styles.
> For example, a comment: The overpainting of the illumination is much
> clearer with the red overlay than the blue. (two targets, each being
> the same area of an image, with a red style and a blue style)
>
> Thirdly, we require a specific resource to have a style or a scope.
> If only scope and style define the specific resource, then it has no
> definition in this case.
>
>
> So ... my proposal is to modify the specific resources module,
> primarily section 3.1,  to be clear that style and scope are important
> aspects that are carried across the re-use of specific resources.  The
> model remains exactly the same, just the definitions change slightly.
>
> Thoughts?
>



Though I was first liking the idea that scope and style are much less essential to what an "annotated resource" is, the temptation to change the semantics as you suggest is really big, i.e. a specific resource "includes" styling and scoping if needed. The issue with the "nature of the triples", which would be different depending on the specifier (some being annotation-scoped, others not), is a big showstopper.

Note that it does not prohibit any form of "resource saving" as you mention in your second point. E.g., a styled resource is based on a non-styled resource, which it gives access to, by traversing one step "up in the specification chain". That non-styled resource can be re-used seamlessly, and give raise to a new, differently styled specific resource if needed. For example
[
:annot1 oa:hasTarget :styledSR1 .
:styledSR1 oa:hasSource :fragment1 ; oa:styleClass "red" .
:fragment1 oa:hasSource :representation1; oa:hasSelector :aSelector .
[etc.]
:annot2 oa:hasTarget :styledSR2 .
:styledSR2 oa:hasSource :fragment1 ; oa:styleClass "blue" .
]
I think this construction is quite valid, both from theoretical and practical standpoints.


I have to admit I didn't fully get your third point. When do "we require a specific resource to have a style or a scope"? Or is it just an hypothetical case, i.e., "*if* we require a specific resource to have a style or a scope"?

Cheers,

Antoine

Received on Wednesday, 30 January 2013 21:21:53 UTC