Re: Specific Resource Semantics

Hi Antoine,

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.


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


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

Thanks!

Rob

Received on Wednesday, 30 January 2013 21:54:39 UTC