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

Re: [web-annotation] Make Selectors available for the wide world?

From: Rob Sanderson via GitHub <sysbot+gh@w3.org>
Date: Sun, 29 Nov 2015 23:35:55 +0000
To: public-annotation@w3.org
Message-ID: <issue_comment.created-160481558-1448840153-sysbot+gh@w3.org>
> RDF people can pull classes and predicates and they do it as their 
hearts' content.
> It is the JSON users that I am really concerned about.

Given that, I don't see the advantage of creating a new namespace for 
just Selectors and their properties, as that community tends to eschew
 namespaces in general.  If we go that route, then I still think that 
at least SpecificResource, State (plus subClasses), Selector (plus 
subClasses) and renderedVia would be the right granularity.  I would 
leave out hasPurpose, hasScope and styleClass as Annotation specific.
  I would be :+1: to that, and :-1: to only Selector (as harmful to 
interop, as above).  The richer namespace would be a useful addition 
to http://www.w3.org/2006/gen/ont

If we go the multiple namespace route, I think we would also want to 
do Content (which had its own NS to begin with, after all) and 
Collections (assuming we can't just use AS2). Both have more utility 
than selectors, especially selectors with no referent, and are 
actively needed in other communities beyond Annotations.  It begins to
 look a bit like namespace soup, but it already does and JSON-LD hides
 it from those that would be offended.

The superclass idea does not work, as far as I understand the 
proposal, as a SpecificResource might /not/ be a segment at all. It 
could be the entire resource with only hasState to record where to 
find the archived copy of the content. Or the entire resource with a 
purpose (e.g. semantic tagging), a scope, a rendering agent, or a 
style.  So I'm also :-1: to that, as it breaks the semantics as 
everything that is true of the superclass (e.g. that it's a segment) 
would not be true of the subclass.  It could be a subclass of 
SpecificResource, but there would be no point to it as it would have 
no properties that weren't associated with its superclass.

A Note that explains how to align with existing approaches would be 
valuable (:+1:) and could be written to target JSON users who have at 
least some sympathy towards semantic interoperability rather than 
purely syntactic.  This seems like something that could be done 
regardless of the namespace mechanics.  Basically:  Use this pattern, 
and put these entries into your context document.  If you don't have 
one, just this one we prepared specially for you.

GitHub Notification of comment by azaroth42
Please view or discuss this issue at 
 using your GitHub account
Received on Sunday, 29 November 2015 23:35:57 UTC

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