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

Re: Specific Resource Semantics

From: Robert Sanderson <azaroth42@gmail.com>
Date: Wed, 30 Jan 2013 15:34:46 -0700
Message-ID: <CABevsUEfSm+e_TXGgyJ1TvVatpfecKwceu9CFov=z-E1vyri4w@mail.gmail.com>
To: Antoine Isaac <aisaac@few.vu.nl>
Cc: public-openannotation@w3.org
On Wed, Jan 30, 2013 at 3:17 PM, Antoine Isaac <aisaac@few.vu.nl> wrote:
> I'm still not sure I get the point then. But from the conclusion I infer
> that we agree.

We do :)

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

Does anyone wish to offer a counter argument?

>>> Note that it does not prohibit any form of "resource saving" as you
>>> 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.

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

Yes, that diagram is not long for this world ;)

> 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

Though it could be a simple algorithm, similar to the list axioms.
While the object of hasSource is a Specific Resource, copy the
properties upwards and replace hasSource with the object of the
hasSource relationship that isn't declared as a Specific Resource.

(And would thus make the class definition useful in a programmatic way)

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

Yes, though the cost of maintaining triples isn't a high priority, it
should be minimized when it can be.

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

Received on Wednesday, 30 January 2013 22:35:13 UTC

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