W3C home > Mailing lists > Public > public-annotation@w3.org > November 2015

Re: [web-annotation] Multiplicity and Collections

From: Jacob via GitHub <sysbot+gh@w3.org>
Date: Thu, 05 Nov 2015 21:46:01 +0000
To: public-annotation@w3.org
Message-ID: <issue_comment.created-154202957-1446759960-sysbot+gh@w3.org>
I think your example (like a lot of examples lately) leans too much on
 document pattern and not enough on what kinds of behavior we expect 
out of the consuming applications. Imagine the following case:

{
  "type": "Sum",
  "items": [ "iron", "iron", "iron", "bonemeal"]  // add these 
together
}
{
  "type": "Print":,
  "items": ["iron", "iron", "iron", "bonemeal"] // render these 
on-screen
}

It looks the same as the as:OrderedCollection pattern...the moral of 
the story is that we can get a huge amount of mileage out of simply 
varying @type . There are many kinds of containers which fulfill 
different roles and demand that different things be done with their 
contents. A grave problem with the activity streams approach is that 
it assumes that only one thing can be done with a list (as though we 
don't used them in actionable fashions everywhere). 

Of potential importance set =/= aggregation; list = set; collection = 
aggregation (ditto for composite). More on this in a couple of weeks.

Closing thought, we've already removed inferencing and reasoning from 
the playing board (which begs the question of why bother with rdf at 
all), are we also to discount our expectations for what consuming 
applications are actually supposed to do with these documents? Or to 
put it another way, if the goal is to produce a general document 
standard for annotation-flavored documents then why not simply work 
directly in the json serialization format? (or xml or html or...).

It's not actually the case that we have no commitments at all to 
inferencing and reasoning...

-- 
GitHub Notif of comment by jjett
See 
https://github.com/w3c/web-annotation/issues/92#issuecomment-154202957
Received on Thursday, 5 November 2015 21:46:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:42 UTC