Re: Semantic tags

Hi Antoine,

On Fri, Apr 3, 2015 at 5:52 PM, Antoine Isaac <aisaac@few.vu.nl> wrote:

> The reasoning was that we didn't want to add a class (oa:SemanticTag) to
>> any arbitrary non-information resource on the semantic web just because it
>> was currently being used in that role for the annotation.  Eventually all
>> resources would have the class and it would be worthless.  So the
>> indirection is to solve that problem.
>>
>>
> Well, I'd consider this not to be a big problem anyway...
>

It does seem unlikely to break things, but we shouldn't be specifying bad
behavior when there's a consistent pattern that fixes it.


> But maybe a solution could be to remove this type altogether?
> I think we had discussed it a couple of years ago for Open Annotation,
> hadn't we?
> An  alternative would be to use another feature, for example an attribute
> of the Annotation itself, maybe a specific motivation (say,
> oa:semanticTagging as a skos:narrower of oa:tagging).
>

This wouldn't work in the case when there are multiple bodies, one of which
is an external comment resource and the other a semantic tag. You wouldn't
know which was which.

So you'd still need a level of indirection, but it might be more consistent
with issue #11 (on github) if the motivation was attached to a
SpecificResource than a new class of SemanticTag.

On the other hand it would be less consistent with regular Tags unless we
also changed that structure to the much more cumbersome:

_:anno1 a oa:Annotation ;
  oa:hasBody _:spec1 ;
  oa:hasTarget <target-uri> .

_:spec1 a oa:SpecificResource ;
  oa:motivatedBy oa:tagging ;
  oa:hasSource _:tag1 .

_:tag1 a oa:EmbeddedContent ;
  rdf:value "tag" .


Thoughts?



> At the time of the original OA design, this other feature might have been
> discarded because typing the body (which was a the concept then) as
> oa:SemanticTag was a simple thing to do.  But if now we have the choice
> between introducing a specific motivation at the Annotation level or the
> indirection, I would go for the specific motivation...
>




>     - why skos:related? Given the sort of semantic tagging scenarios we
>> (and I believe anyone else) have, the link is much stronger from a semantic
>> perspective. I'd have expected skos:exactMatch.
>>
>> A good question, and one that I don't find the answer to immediately.  I
>> think that exactMatch could be used instead of related, which does seem a
>> much weaker statement.  The intended semantics of the relationship are
>> similar to that of foaf:page, but instead the object is the concept
>> directly.  Happy to go with your opinion on which predicate makes most
>> sense there!
>
>
> Yes skos:exactMatch seems fine. Better, in any case!
>

Created issue #29 to do this, and will close if we move to a model along
the lines of above.

Thanks!

Rob

-- 
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305