Re: Semantic tags

On Thu, Apr 23, 2015 at 12: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
> :-)
>
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


As you know, I would be very happy to get rid of the literal body pattern!
It makes the model inconsistent, makes the serialization inconsistent, and
it doesn't make anyone's life easier.  That the tag vs literal body model
is inconsistent is the fault of the literal body pattern being tacked on,
and being inconsistent with *everything*.



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


Multiple bodies with different motivations.

A machine could not distinguish which body is a tag and which is the
comment:

{
  "@type": "oa:Annotation",
  "motivatedBy": [oa:tagging, oa:commenting],
  "hasBody": [ "<3", "I love this"],
  hasTarget" : "http://example.org/"
}

What is needed is yet another restriction to say that the literal string
MUST be interpreted as if it had the class dctypes:Text, and no other
classes, to resolve this ambiguity.


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

As above.


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

The use cases are pretty clear, actually.  People tag things with wikipedia
documents, as that's the URI that they have, but mean the concept the
document describes.  Paolo had a lot of examples of this in the bio domain.
Better systems would allow the use of the dbpedia equivalent URI for the
concept, such as Bernard's maphub system.

So there's two existing systems from this community that have the
requirement, I'm sure it would not be hard to find others.

Users just take the concept and connect it to the document.


Most users don't have a client that has access to URIs that identify
concepts, so I disagree that's what users do.



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


While we have multiple bodies, then we need the additional nodes.
Provenance of the body should be on the body, not the annotation which
might have a very different provenance.

The use cases for multiple bodies are also pretty clear:  Annotator and
clones create annotations with both comments and tags. Exporting bookmarks
from a browser creates annotations with both comments and tags.

Rob

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

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