Semantic tags issues (was: Re: Last Ultimate Final Call )

Hi,

It looks elegant, but I have huge doubts on whether it fits the current SR framework well. In SRs, source is currently rather a document engineering affair. Broadening it to some vague notion of "conceptual derivation" seems dangerous. There are plenty concepts to derive from one document...

In fact I'd be reluctant to adding anything on this in the current doc. The OA model should assume that there are semantic tags available for use in annotations, not write a guide on how to create them from document URIs. If there is need for something else, please put it in another document!

And of course I fully subscribe to:
[
Using documents as *semantic* tags is simply bad modeling.  Do you
mean the document or the semantic concept (eg my home page or me).
Surely this has been discussed long enough in other contexts that we
don't have to rehash it here?
]
in case anyone feels a need to adding something on the issue in the current doc.

About the mail exchange between Stian and Rob at
http://lists.w3.org/Archives/Public/public-openannotation/2013Feb/0002.html
and
http://lists.w3.org/Archives/Public/public-openannotation/2013Feb/0007.html
I am not sure what the conclusion is, but it seems to me that the current solution:
- is not too horrible wrt. the open world assumption: assuming that a cnt:char will be present for a non-semantic tag is not too exaggerated, because this is what the spec *mandates* for these tags.
- allows for semantic tags to co-exist with non-semantic ones and other kinds of bodies.
- allows for composite of tags (which would themselves be tag, similar to some SKOS extensions to combine concepts together)

Worst case, if there's still doubt on how to distinguish semantic tags from the rest, I would prefer to include a new class oa:SemanticTag. The alternative solutions (oa:semanticTagging dictating only one body, oa:semanticTagging influencing the interpretation of all hasBody statements) seem worse to me. Even though Rob's statement on one of the options
[
That kills, for example, the use case of extracting the semantic tags
from the textual description (eg regular body) and having them in the
same Annotation.
]
seemed a bit strong. It would still be possible to treat the text in some annotation provenance field (e.g. dc:source) which doesn't seem conceptually wrong.


Cheers,

Antoine



> No doubt that is elegant solution with respect of the rest of the model.
>
>
> On Fri, Feb 1, 2013 at 1:31 PM, Robert Sanderson <azaroth42@gmail.com <mailto:azaroth42@gmail.com>> wrote:
>
>     On Fri, Feb 1, 2013 at 11:22 AM, Paolo Ciccarese
>     <paolo.ciccarese@gmail.com <mailto:paolo.ciccarese@gmail.com>> wrote:
>      > On Fri, Feb 1, 2013 at 1:09 PM, Robert Sanderson <azaroth42@gmail.com <mailto:azaroth42@gmail.com>>
>
>      >> > So how about recommending to do #tag on the URI of the page?
>      >> > Like: http://omim.org/entry/104760#tag
>      >> > Again, not ideal but it could help. No?
>      >>
>      >> This is what we recommend already, using a different URI and linking
>      >> it to the document :)
>      >
>      > Wait, that is exactly my point. Not 'a different URI' in general, that would
>      > create a mess I believe.
>      > How do we feel in pushing for a specific way of using "the different URI"
>      > #something?
>
>     I don't like it, especially with the clarification in RDF 1.1 that
>     fragments identify the element within the hosting format, not a
>     semantic resource.
>
>     http://www.w3.org/TR/rdf11-concepts/#section-fragID
>
>     So if there was a "tag" in the underlying document, then it would
>     refer to that, not the use of the URI as a semantic tag. It still has
>     the same collision problems.
>
>     The clean way, IMO, is:
>
>     <anno1> a oa:Annotation ;
>     oa:hasBody <tagSpRes1> ;
>     oa:hasTarget <target1> .
>
>     <tagSpRes1> a oa:SpecificResource , oa:[Semantic]Tag ;
>     oa:hasSource <http://omim.org/entry/104760> ;
>
>     Which is just a clarification of what we already say in the doc, that
>     you mint a new URI and link it to the original URI.
>
>     Rob
>
>
>
>
> --
> Dr. Paolo Ciccarese
> http://www.paolociccarese.info/
> Biomedical Informatics Research & Development
> Instructor of Neurology at Harvard Medical School
> Assistant in Neuroscience at Mass General Hospital
> Member of the MGH Biomedical Informatics Core
> +1-857-366-1524 (mobile) +1-617-768-8744 (office)
>
> CONFIDENTIALITY NOTICE: This message is intended only for the addressee(s), may contain information that is considered
> to be sensitive or confidential and may not be forwarded or disclosed to any other party without the permission of the sender.
> If you have received this message in error, please notify the sender immediately.

Received on Sunday, 3 February 2013 19:37:10 UTC