Re: Last Ultimate Final Call :)

On Fri, Feb 1, 2013 at 9:20 AM, Stian Soiland-Reyes
<soiland-reyes@cs.manchester.ac.uk> wrote:
> 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.

Sure, and for non information resources, you can use URIs that already exist.

http://dbpedia.org/resource/Paris doesn't identify a document, so
there's no confusion as to whether to dereference it or not.

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?


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

None? We could change it to a class, like Halpin's
NonInformationResource, that's clearer that it just means that the URI
identifies something that isn't a document and hence doesn't need to
be dereferenced, but that seemed clunkier, especially at the
intended-to-be-simple core level.

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

Of course, people can assert all sorts of crazy things about
resources.  Ali Hasnain, Tom Heath et al had a great paper last year
about this sort of thing and the trouble it can (will?) cause:
    http://ceur-ws.org/Vol-905/HasnainEtAl_COLD2012.pdf

But to assert that a non information resource, the city of Paris, has
content is clearly wrong.

> For instance,
> semantic tags identifying genome sequences might very well be
> including the actual genome sequence (like "GATTATTATATATATAGATTACA"
> as cnt:chars.

And that too would be wrong.  The biological genome in the real world
does not contain a string of characters in UTF-8 like that.


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

Yes, but that particular plague makes everything practically unusable.
 Does this specific resource have a state? I don't know! How many
targets are there for the Annotation? I don't know, there could be
others that I don't know about! Does this Annotation have a body? I
don't know, please just let me get on with my job! etc. :)


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

Yes. Semantic Tagging would be limited to exactly one body, which is
the semantic tag, and nothing else.  So no multiplicity either with
other semantic tags, textual tags or regular bodies.

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.

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

Yes, agreed.  Is it a semantic tag or not. Currently it's unclear.
The introduction of a oa:semanticTagging Motivation that explicitly
said that all of the objects of the oa:hasBody relationship are URIs
intended as semantic tags, would clear that up, but ...


> 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, along with the motivation, also doesn't work with multiplicity constructs.

eg:

<anno1> a oa:Annotation ;
  oa:hasSemanticTag <composite1> ;
  oa:hasTarget <target1> .

<composite1> isn't intended as a semantic tag. But if we allow any URI
to be used as a tag, nothing prevents someone from saying it is. So
already we have trouble.
Plus:

<composite1> a oa:Composite ;
  oa:item <semantictag1> ;
  oa:item <textualbody1> .


Here, <textualbody1> is the resource that <semantictag1> was extracted
from.  The semantics of Composite are that all of the items are
required, which is what the publisher wants to convey.
Except textualbody isn't a tag. Nor is composite1.  This is the same
argument as against a new predicate for literals as bodies.


So I agree with you 110% that the oa:Tag class is not ideal, the
alternatives are all either much more restrictive or at least as
problematic for the use cases that have been expressed.

If there's a solution that allows a mix of body types, I would be
overjoyed!  But I can't see how to do that without introducing any of:
1. a node in between (as current spec for documents); 2. a class or
other property (as current spec for non documents); or 3. a new
predicate (that gets us in trouble)

Rob

Received on Friday, 1 February 2013 17:18:46 UTC