Re: Semantic tags

Hi Rob,

Sorry for taking so long to answer...
I'll just focus on the semantic tag issue.

Indeed the solution I had dug up ('semantic tagging' motivation) would not work well with annotations with several bodies of different types.

I'm not sure I buy the solution with the SpecificResource. As you say it still has one level of indirection, so it won't solve my worry.

Perhaps the one thing that would solve it would be to use a specific sub-property of oa:hasBody to indicate that the target is a semantic type (i.e. oa:hasSemanticBody). It was also considered a couple of years ago... and discarded, probably (I don't remember for sure) because it introduces heterogeneity to the core pattern of the Annotation data.
That being said, the solution with the blank node also breaks the pattern, big time. One expects to find something useful as the object of the oa:hasBody triple, but it's not really there: one now to make specific rules to go one step beyond, for the case of semantic tags...
Though I reckon that for the JSON-LD serialization it may be less harmful than the sub-property trick.


At this point I must apologize for playing the devil's advocate and testing these old options again on you.
As you've read I've been quite surprised (and displeased) with the new semantic tagging pattern. And maybe it's good if the new WA spec can claim to have considered all alternatives (and we're actually doing it quite quickly here, at least way quicker than in the OA times!)

Cheers,

Antoine

On 4/3/15 7:10 PM, Robert Sanderson wrote:
>
> Hi Antoine,
>
> On Fri, Apr 3, 2015 at 5:52 PM, Antoine Isaac <aisaac@few.vu.nl <mailto: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

Received on Monday, 20 April 2015 19:07:16 UTC