- From: Jacob Jett <jjett2@illinois.edu>
- Date: Thu, 23 Apr 2015 08:24:48 -0500
- To: Antoine Isaac <aisaac@few.vu.nl>
- Cc: W3C Public Annotation List <public-annotation@w3.org>, Hugo Manguinhas <Hugo.Manguinhas@europeana.eu>
- Message-ID: <CABzPtBK6hehi+uQ4MP480M8mepL+Y2HwE7L_AR8p3oS22KHJkQ@mail.gmail.com>
Hi Antoine,
As I recall the reason to differentiate between simple text tags and other
kinds of textual bodies was to address a multiple bodies use case where
some of the bodies are tags and others are fuller text descriptions. In
this case I can't simply stick a single overarching motivation of "tagging"
onto the annotation.
While having both kinds of simple text bodies complicates the overall
model, it provides some low level tools for disambiguating multiple,
heterogeneous annotation bodies.
Regards,
Jacob
_____________________________________________________
Jacob Jett
Research Assistant
Center for Informatics Research in Science and Scholarship
The Graduate School of Library and Information Science
University of Illinois at Urbana-Champaign
501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
(217) 244-2164
jjett2@illinois.edu
On Thu, Apr 23, 2015 at 2:00 AM, Antoine Isaac <aisaac@few.vu.nl> wrote:
> Hi Rob,
>
> You had almost convinced me with the previous mail that the solution was
> indeed the best, even if not ideal. But reading your new email I'm doubting
> :-)
> When I see
> [
> * 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)
> ]
> Actually I'm surprised to realize that OA now has two solution for simple
> text annotation: the simple text as body and 'textual tags'.
> http://www.w3.org/TR/2014/WD-annotation-model-20141211/#tags
> http://www.w3.org/TR/2014/WD-annotation-model-20141211/#simple-textual-body
>
> I don't see anything in the spec that tells why a simple annotation with
> text body and oa:tagging motivation would fail to capture the requirements
> that the 'textual tags' meet. The textual tags are more complex, and they
> make the system of motivation more fragile, because of part of their
> function is now taken by the oa:Tag class. That's not coherent, and there's
> no serious reason given for it.
>
>
> Back to semantic tags, honestly your requirement #2 is fishy for me, as it
> seems it makes a set of technical design constraints and choices (the ones
> that lead to the current solution) parade as higher-level needed.
>
> Users just take the concept and connect it to the document. The same way
> as in a literal scenario they type something and they don't mean 'oh, here
> I'm adding a symbol in a computing system, and this set of characters is
> actually different from the same set of characters I'll type 5 minutes
> later to tag another document'...
> No intellectual construct between 'concepts' and 'tags' in there, please!
> All provenance or 'context-specific' stuff that may motivate it should go
> at the level of the annotation resource.
>
> Antoine
>
>
> On 4/21/15 3:21 AM, Robert Sanderson 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
>> <mailto: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> <mailto: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
>>
>
>
Received on Thursday, 23 April 2015 13:25:57 UTC