W3C home > Mailing lists > Public > public-openannotation@w3.org > January 2013

Re: Specific Resource Semantics

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Wed, 30 Jan 2013 23:17:17 +0100
Message-ID: <51099BED.3040408@few.vu.nl>
To: <public-openannotation@w3.org>
Hi Rob,

> On Wed, Jan 30, 2013 at 2:21 PM, Antoine Isaac<aisaac@few.vu.nl>  wrote:
>> On 1/30/13 7:30 PM, Robert Sanderson wrote:
>>> The question is which relationships and properties *define* the nature
>>> of the Specific Resource, and which are just informational or
>>> contextual (if any).
>>> This leads to an issue with the global nature of triples,
> This is, as you say, the showstopper.
>>> 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.
> By this I meant something different to how you interpreted it.


> If the identify of a specific resource is only determined by State and
> Selector, then it is odd that there should be two semantically
> identical specific resources (say sptarget1 and sptarget2) that also
> have different scopes or styles.
> If adding a style does not necessitate a new identity, then the
> resources sptarget1 and sptarget2 should have the same identifier.
> But of course it does, and therefore style must contribute to the
> distinction between the two.

I'm still not sure I get the point then. But from the conclusion I infer that we agree.

>>> 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.
>> 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"?
> Just hypothetical.
> As an extension of the second point, if (hypothetically) only State
> and Selector define the identity of a Specific Resource, then what is
> the identity of a specific resource that doesn't have either of them?
> Yes, it intuitively is the Source with the Style or Scope ... but
> that's not what we say in the specification.

Ok, yes, this third point was then also a rather good argument for our common position.

>> 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".
> [...]
>> I think this construction is quite valid, both from theoretical and
>> practical standpoints.
> Ahha, now that is very clever.  I don't think we've ever discussed
> specific resources where the Source is a specific resource.  I don't
> see any reason why it would be invalid, as we don't constrain the
> range of oa:hasSource, and hence a Specific Resource could be the
> object of the predicate.
> On the other hand, it does lead to many different ways to describe the
> same thing.  Some specific resources which have the "real" source
> resource with all of the specifiers, and others which chain them via
> multiple intermediary specific resources.
> I would be happy to not change the spec to say you can't do this, but
> not sure we should draw immediate attention to it?

In fact it was again Fig 3.1.1 which tricked me into this. By presenting a chain of specific resources, I hypothesized a graph of chained specific resources was also possible.

I agree not changing the spec is very tempting. This leaves room to different choices to co-exist. But there are drawbacks too, and I'd understand if the group judged it relevant to kill the issue now.
To sum up, the "chained specific resources" option:
1. potentially harms interoperability, and makes processing for clients more cumbersome: they would have to check whether a source is itself a specific resource, in order to get all the required context
2. potentially saves a lot of triples, even without considering cross-application re-uses. E.g. if in an application many annotations are made about different fragments of a representation, then the triples defining that representation (oa:hasStates and the various triples attached to the State) don't need to be repeated.

I'm really sorry again, I couldn't figure out I would open a new can ;-)

Received on Wednesday, 30 January 2013 22:17:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:38:21 UTC