Re: Semantic tags

Hi Antoine, all,

To summarize the requirements:

1 Use a URI as a tag for a resource, rather than a string that is likely to
be ambiguous
2 Allow both the concept described in a referenced document, and the
concept itself as the tag
3 Do not pollute the knowledge graph about the concepts or documents by
specifying annotation-specific information about them
4 Must work with multiple bodies, and multiple motivations


And the options:

* Add a class or property to the concept URI, as per oa:SemanticTag in the
CG draft.
  -- Bad as it breaks 3, prompting the change from the CG structure

* Have a new predicate between annotation and resource as subProperty of
hasBody
  -- Bad as now clients need to look in multiple places for tags versus
semantic tags,
    Also sets a bad precedent for communities to do the same, making
finding the body of an Annotation much harder in general.  It would mean
generating new contexts for every community that did this, compared to
minting new motivations which go in the value in the JSON rather than the
key.

* Add a class or property to the annotation, such as the SemanticTagging
motivation
  -- bad as it breaks 4 (as discussed)

Meaning we need some sort of reified intermediary node:

* Have an intermediary node as a SpecificResource with the tagging
motivation
   -- Inconsistent between tags (direct body) and semantic tag (referenced
from SR) without making easy things hard, which we should avoid.

* Include an intermediary Tag node for semantic tags, and relate the Tag
node to the concept.
   -- Current model


The strengths of the current model are:
  * it's consistent for literal Tags and the two variants of Semantic Tag
    There's a resource, which has either a string literal (Tag with
rdf:value) or a URI (Tag with foaf:page or skos:exactMatch)
  * it doesn't break any of the requirements
  * if copied, it doesn't mean new contexts all the time
  * it doesn't encourage proliferation of predicates

We could even dispense with the current SemanticTag class and just let
clients introspect on the properties to figure out which type it is, but I
don't see any harm in distinguishing the two as we currently do.  I'm
certainly open to any sort of streamlining that can be done.

So I unless there's a solution I'm missing, I feel like we have the best
option at the moment.  Proposals are very welcome, of course!

Rob



On Mon, Apr 20, 2015 at 11:56 AM, Antoine Isaac <aisaac@few.vu.nl> wrote:

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


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