Re: Specific Resource Semantics

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


Yes! But in RDF-based environment, replacing a resource is quite difficult. You'd have to create a new (internal) graph to be sure not to have several oa:hasSource statements co-existing.


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


Yes, and I think here the saving is not only technical. The pattern also allows re-using bits of data and prevents some deeper semantic questions: in my specific example, it will prevent worrying about whether all these states with the same properties are indeed the same entity or not.

Antoine

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

Received on Thursday, 31 January 2013 11:17:22 UTC