Re: Semantic tags

Hi Jeff,

By "knowledge graph", I just meant the global graph of RDF statements. We
shouldn't be making assertions (such as adding spurious, context-dependent
classes) about other people's resources.

Apologies for the confusion!

Rob


On Mon, Apr 20, 2015 at 6:42 PM, Young,Jeff (OR) <jyoung@oclc.org> wrote:

>  So annotation graphs are objectively distinct from knowledge graphs?
>
>  What is the distinction? Aren't all RDF descriptions a subjective
> annotation of reality? Is this a Turing test?
>
>  On Apr 20, 2015, at 9:22 PM, Robert Sanderson <azaroth42@gmail.com>
> wrote:
>
>
>
>  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
>
>


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