RE: issues with skos:related and Semantic Tags

Good discussion.

> inferring the type skos:Concept does not add any further semantic implications
> non-intrusive way to relate to "any kind of identified concept".

> (if no blank node) those also become oa:Tag instances - so dbr:Paris would
> become a oa:Tag - which I think is more intrusive than saying it is a skos:Concept 

> NOT RECOMMENDED to use the URI of a document
> as a Semantic Tag, as it might also be used as a regular Body in other
> Annotations which would inherit the oa:SemanticTag class assignment.

I don’t see why one is more intrusive than the other.
In particular, I don't see why oa:SemanticTag would prevent using the same resource as a body.
In any case, I don't see how skos:related decreases pollution of the target resource, and so the blank node used is IMHO parasitic.

In contrast: in the beginning there were classes oa:Target and oa:Body and some wording or ranges that bound oa:hasTarget and oa:hasBody to those classes.
Which was quite wrong, given that one's Body can be another's Target.

In general, I think that the role of a resource in relation to any application (considering OA an application) should be expressed by, well, app-specific *relations* to that resource, not added *types* on the resource.

oa:SemanticTag is IMHO quite useless, because it's the conjunction of oa:motivation oa:tagging, with the virtue of being a resource.
SPARQL can discover this virtue easily, can't JSONLD also do it?

Received on Tuesday, 15 September 2015 07:52:10 UTC