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

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

You cut out part of my quote, which is:

>> RDF people can pull classes and predicates and they do it as their 
hearts' content. There may be a healthy reluctance, though, to do that
 if it is part of a larger and more complicated vocabulary, hence my 
proposal to put it into a separate namespace. Really, doing that on 
the RDF side is just syntactic sugar at this point.

On your other comments:

> 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

You keep saying that, and I disagree... I did give you examples of 
pure ``Selector`` usage. I do not see why ``State`` and 
``renderedVia`` would have an intricate relationship with 
``Selector``. To use my example, assigning an ONIX metadata to a 
specific portion of a document, if needed, has nothing to do with 
state or via.

To use your voting technique:-): :-1: on adding ``renderedVia`` and 
``state`` to such a separate namespace. And :+1: to the Selector 
separation and I have no idea why you say that it is harmful for 
intro.

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

You either completely misunderstood what I said or (which I do not 
suppose) you seem to have some misunderstanding on the way the RDF 
semantics work. I suppose it is the former, because under the RDF 
semantics whatever you describe in this section is not a problem 
whatsoever. To make things clear to those among us who may not be 
familiar with all the details of RDF, here is a summary of what I 
proposed in this.

1. We define a separate RDFS Class called (for now, 
``selector:SelectorResource``
2. We move the properties ``source`` and ``selector`` properties into 
the ``selector:`` namespace; the ``refs:domain`` for these properties 
are defined to be ``selector:SelectorResource``
3. We move the current ``Selector`` class and corresponding properties
 into the the ``selector:`` namespace
4. We define ``SpecificResource`` as a subclass of 
``selector:SelectorResource``

What #4 means is that if an instance ``x`` is of type 
``SpecificResource`` then it is also of type 
``selector:SelectorResource``. But if the triple ``(y selector:source 
w)`` holds, we can deduce that ``y`` is of type 
``selector:SelectorResource`` but not *necessarily* of type 
``SpecificResource``. That is *all* what these things mean. Put into 
human terms, applications may use ``selector:SelectorResource`` with, 
possibly, ignoring annotations, whereas annotations can use the same 
structures as before without any further problems.

This does *not* say anything about what properties are used for a 
``x`` resource. It may or it may not use a selector, it may or may not
 use solely the ``hasState`` as you mention, or scope, or style, or 
whatever. Put it clearly: I simply do not see where this setup would 
break anything on the semantics of ``SpecificResource``. Defining a 
domain for a property is just a license to deduce something, and is 
not defining obligatory properties. (RDF Classes are not the same as 
classes in a language like C++ or Python).  

I maintain that having these in a separate namespace is enough, that 
it is an almost zero level editing on the current vocabulary, it does 
not break anything, but would be of a great value to the community. 

We seem to fundamentally disagree on this, and that is fine. This 
happens. I think the decision should be done by the WG now.

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

I am not sure what you mean by "some sympathy towards semantic 
interoperability rather than purely syntactic": I think that would be 
useful for any JSON user. 






-- 
GitHub Notification of comment by iherman
Please view or discuss this issue at 
https://github.com/w3c/web-annotation/issues/110#issuecomment-160566248
 using your GitHub account

Received on Monday, 30 November 2015 09:16:08 UTC