Re: Semantic tags

Hi Rob,


Sorry for taking so much time, but I'm really overwhelmes, and these things take time.
(actually this is the second version of my answer ; I had written a first draft and then a couple of days later realized I had misinterpreted something and had to re-write!)


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



Yes there might need to be a re-consideration. Moving to simple literal was good, but if the spec keeps/add some other patterns at the same time, which makes the simple literal conflict with the rest, I agree it's not good.


>
>
>     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/"
> }



Well in such example I don't see why one needs to represent both motivation in one annotation. This could be two annotations. Actually the user is probably not entering these two things at the same time and in the same textbox...
Actually in the end I think what I really don't buy is the idea of these complex Annotation that have different types of tags and especially different motivations. I'm all for splitting annotations into elementary components, especially as I suspect 'compound' annotations might be an artefact linked to UI (allowing different things at the same time) rather than conceptual. But well, I'm also ok accepting I'm the only one thinking this :)



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


I'm not convinced, by the above - at least not yet.


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


OK, I get it. I had actually misunderstood the pattern since the beginning I think.
Looking at Fig 8 at http://www.w3.org/TR/annotation-model/#semantic-tags
I had forgotten this was a page. Still I think that the blank node in Fig 8 could be considered to be some kind of concept. Concepts have foaf:pages (or even better foaf:primaryTopic). This would be nicely consistent with having a concept be the (direct) body in Fig 7.
Or maybe it would create inconsistencies with other parts of the spec, but now I'm a bit lost.



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


I'm uncomfortable with this statement, when the 'provenance of the body' is so con-substantial to one annotation action.


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


See my comments above. I don't see what would hurt if exporting bookmarks create one annotation for the comment and one for the tag. It's more verbose but much more granular, and could have advantages. Especially when there's only a tag and no comment...

Cheers,

Antoine

Received on Tuesday, 12 May 2015 08:04:31 UTC