Re: Specific Resource Semantics

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 ;-)
:)

Rob

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