Re: Last Ultimate Final Call :)

On second thought, I have some concerns about oa:Tag.


> The case of an embedded tag versus an embedded textual resource may be distinguished by the presence of the oa:Tag class. It is possible to distinguish a semantic tag URI from an embedded textual tag that also has a URI and the oa:Tag class, by the presence of the cnt:chars predicate which MUST be present for embedding resources.

> It is NOT RECOMMENDED to use the URI of a document as a semantic tag, as it might also be used as a regular Body in other Annotations which would inherit the oa:Tag class assignment. Instead a new URI should be created and linked to the document using an ontology appropriate to the situation.

This does not work. If I am to make a semantic tag - then I would want
to use the URI that already exist! I can't just make my own. How do I
relate my new term with the URI I wanted to use? I am forced to invent
my own vocabulary for semantic tagging.

Also as the URI is a term from an existing vocabulary, there could be
many different things said about it already. Let's say the semantic
tag is <http://dbpedia.org/resource/Paris> like above.  What is the
impact of other users of <http://dbpedia.org/resource/Paris> to type
this as oa:Tag? How can we know those users have not included a
cnt:chars value already? Remember that cnt:chars is not 'our' property
and therefore could have been used for other purposes. For instance,
semantic tags identifying genome sequences might very well be
including the actual genome sequence (like "GATTATTATATATATAGATTACA"
as cnt:chars.

The definition of some property NOT existing on a resource is also a
bit at odds against the "open world assumption".



I think this style can remain for *textual* tags:

  <anno1> a oa:Annotation ;
    oa:motivatedBy oa:tagging ;
    oa:hasBody <body1> ;
    oa:hasTarget <target1> .

  <body1> a oa:Tag, cnt:ContentAsText ;
    cnt:chars "tag" .

That is because <body1> here really represent a textual tag (so oa:Tag
is ok), and a tag is very well expected to have a textual
representation (so cnt:chars is OK).


But for semantic tag I would instead propose:

  <anno1> a oa:Annotation ;
    oa:motivatedBy oa:semanticTagging ;
    oa:hasBody <term1> ;
    oa:hasTarget <target1> .

  <term1> a :anything ;
      cnt:chars "GATTTTTTTTACA" # would be allowed but has nothing to do with OA

Here there are absolutely no requirements for <term1>. It is merely
the purpose oa:semanticTagging (which is more specific than
oa:tagging) that tells us this is a semantic tagging. This means that
in this semantic tagging I can't also include oa:hasBody to "classic"
bodies.

If <term1> here also is already an oa:Tag from elsewhere, that is OK,
and this semantic tag is also a textual tag we can understand.


If oa:semanticTagging is skos:narrowerThan (?) oa:tagging, then
semantically this would still leave open for this unclear:

 <anno1> a oa:Annotation ;
    oa:motivatedBy oa:tagging ;
    oa:hasBody <body1> ;
    oa:hasTarget <target1> .

  <body1> a :notATag .
    # with no cnt:chars

But we can assume this is some other kind of, perhaps more domain
specific, tagging. Perhaps <body1> is a complex tagging structure. We
can fall back to just following the link for <body1> and hope for
something useful.



Alternatively, bring back an old friend instead of oa:hasBody:

 <anno1> a oa:Annotation ;
    oa:motivatedBy oa:tagging ;
    oa:hasSemanticTag <term1> ;
    oa:hasTarget <target1> .

For simplicity oa:hasSemanticTag can be a subproperty of oa:hasBody.
This would avoid the above situation, and also allow mixed use, like:


 <anno1> a oa:Annotation ;
    oa:motivatedBy oa:tagging ;
    oa:hasSemanticTag <term1> ;
    oa:hasBody <term1> ; # implied
    oa:hasBody <body1>, <body2> ;
    oa:hasTarget <target1> .

<body1> a oa:Tag, cnt:ContentAsText ;
    cnt:chars "gene" .

<body2> cnt:ContentAsText ;  ## Not a textual Tag, classical body!
    cnt:chars "I tagged the genes to <term1> above" .


On Fri, Feb 1, 2013 at 3:55 PM, Robert Sanderson <azaroth42@gmail.com> wrote:
> To summarize the changes, before Monday's launch:
>
> On Mon, Jan 28, 2013 at 4:08 PM, Robert Sanderson <azaroth42@gmail.com> wrote:
>
>> Antoine:
>> * Homogeneity of JSON context names
> Done.
>
>> * Named / Embedded Graphs
> Rewritten and reordered as suggested.
>
>> * Lists and Containers
> Choice and Composite are subclasses of Alt and Bag, List is
> dual-classed with an extensive note describing the issues.
>
>> * Specific Resources with Style and Scope
> 3.1 rewritten to not include the diagram, and clarify that style and
> scope are included in the definition of the identity of the specific
> resource.
>
>> * Lack of consensus on Textual Bodies
> No change.
>
> Rob
>



-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Friday, 1 February 2013 16:21:35 UTC