Re: [model] Modeling a Tweet: Tags

Hi, Jacob–

On 6/18/15 5:00 PM, Jacob Jett wrote:
> Looking at the pattern Doug proposes I have a few questions in-line below.
>
> On Thu, Jun 18, 2015 at 2:25 AM, Doug Schepers <schepers@w3.org
> <mailto:schepers@w3.org>> wrote:
>
>     Hi, folks–
>
> {snipped stuff we've already discussed}
>
>     How can we model this?
>
>     The best I could come up with is to duplicate the hashtags in both
>     the comment body and in their own bodies. Here's some example
>     JSON-LD (please excuse the imprecise/incorrect inclusion of
>     motivation on each body, it's just illustrative.):
>
>     {
>        "@id": "https://twitter.com/azaroth42/status/607727122975739905",
>        "@type": "oa:Annotation",
>        "annotatedBy": "https://twitter.com/azaroth42/",
>        "annotatedAt": "2015-06-07T12:00:00Z",
>        "serializedAt": "2013-02-04T17:53:00Z-8",
>        "body": [
>          {
>            "@id": "http://example.org/body1"
>            "motivation": "oa:commenting",
>            "value" : "Been a while. Indexing my phd thesis transcription
>     as #openannotations towards #iiif search demo implementation",
>          },
>          {
>            "@id": "http://example.org/body2"
>            "motivation": "oa:tagging",
>            "value" : "openannotations",
>          },
>          {
>            "@id": "http://example.org/body3"
>            "motivation": "oa:tagging",
>            "value" : "iiif",
>          }
>        ],
>     }
>
> I suppose my first question is, do you need to dump out the content like
> this? If the tweet already has a URL, couldn't you just have a pattern
> like "value" : "URL" ? Does the extra granularity add something to this
> annotation?

I don't understand.

I'm not suggesting annotating the tweet, I'm trying to model the tweet 
itself, as if this were what Twitter's API might send down the pipe to a 
Twitter client.



> Assuming body2 and body3 are "about" the target then what you have here
> should be ok (also assuming body2 and body3 are specific resources).
>
> If however, body2 and body3 are about body1, then we need a different
> approach.

No, each body is about the target, per the spec [1]:

[[
Each Body is considered to be equally related to each Target 
individually, rather than the complete set of Targets.
]]

In this case, there isn't a target, so it's not a very good annotation, 
but it's a fine message, and I suspect a successful annotation client 
will deal with target-less messages as well as annotations, so we should 
be able to model them, too.

I don't think it's a useful exercise to speculate on whether the bodies 
are "about" each other, as a generalized case. We've gotten into that on 
other threads, and as I've tried to express (and perhaps you might have 
tried to express as well), it's hard to assume intent from a lossy UI.

The user made a comment, added some tags; they didn't (and wouldn't) 
spend time specifying the entailment for which tag applied to which body 
or target. They might not know themselves. It's probably not a rigorous 
exercise in precision for the benefit of machine understanding, it's 
just a message.



> We've already discussed modeling it as separate annotations
> but, we could also model body1 as a named graph (i.e. structured body).
> This is advantageous because it would let us import and preserve the
> contextual information regarding what roles the content of body2 and
> body3 play in the tweet document. The downside is more structure and
> more complicated implementation (for what goes into body1's value anyway).
>
> This is sort of like Doug's idea of nested bodies.

I never suggested nesting bodies.

I only suggested clustering multiple bodies into a single 
body-container, similar to the example for multiple bodies and targets 
in the spec (Example 21) [2].

It's possible that I misunderstood that example; if so, please let me know.


> Nesting bodies (and targets) has also been broached in the past.
> Almost nobody liked this idea though because, HyTime...

I don't get the reference/joke.


> Of course if RDF containers already worked like this...

How do RDF containers work, if not like this?


[1] http://www.w3.org/TR/annotation-model/#multiple-bodies-or-targets
[2] http://www.w3.org/TR/annotation-model/#eg11-1

Regards–
–Doug

Received on Thursday, 18 June 2015 22:01:52 UTC