Re: [model] Modeling a Tweet: Tags

Hi Doug,

Remarks in-line.


On Thu, Jun 18, 2015 at 5:01 PM, Doug Schepers <schepers@w3.org> wrote:

> 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.
>
> I'm not certain why you would want to do this but I am sure that the
correct way to do this would be by representing the tweet as a kind of
structured document that acts as the body of an annotation. This would
allow you to differentiate between the different content-bearing structures
within the tweet.


>
> > 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'd argue that there is a target, it's just not one that exists in a
realized form. It's an abstract thing, a non-information resource like a
FRBR work. That being said, it could be (and perhaps should be) represented
by an arbitrary node, like a blank node, that can at least bear some
metadata that describes the abstract thing.


> 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.
>
>
Sorry, I misunderstood what you were going for. We already have a good way
to cluster body content (detailed in section 5 of the fpwd).


> 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].
>
>
Right, the best way to achieve this would be to use a composite body -- see
5.2 (http://www.w3.org/TR/annotation-model/#composite). A more complex
alternative would be to represent the body as a named graph (this would
allow for a more document-centric data model to be imported).


> 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.
>
>
A couple of years back it was pointed out that if we could use specific
resources as the object of a triple involving the oa:hasSource predicate
then we could drill into documents at multiple levels of granularity or
apply multiple selectors without using the added indirection of the
rdf:List container. This is a concept from HyTime which is an ancient SGML
application / markup language that no one really liked (in fact I think it
was universally reviled) because, while it had useful features like this
one, it was overly verbose. Of course if RDF containers (or specifically
RDF lists) had stolen some of its concepts its arguable that they might be
somewhat less clunky. Of course the risks for people building infinitely
recursive models would also multiply.


>
> > Of course if RDF containers already worked like this...
>
> How do RDF containers work, if not like this?
>
>
RDF containers are passably good for unions and intersections but their
list structures leave alot to be desired, mostly because they are nesting
sub-graphs rather than just nesting assertions.


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


Regards,

Jacob