Re: Semantic tags

The assertion that the resource is a semantic tag is only true in the
context of the annotation, and meaningless outside of it.
So while I agree with the owl:sameAs pattern, it's a different question
than the one that's the answer for :)

Rob

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

>  Wouldn't it be OK to make assertions about other people's resources if
> you coined URIs for those resources in your own domain and then asserted
> owl:sameAs?
>
>  I guess it's not clear what "context-dependent class" means.
>
> On Apr 20, 2015, at 11:11 PM, Robert Sanderson <azaroth42@gmail.com>
> wrote:
>
>
> 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
>
>


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