W3C home > Mailing lists > Public > public-annotation@w3.org > January 2016

Re: [web-annotation] Multiple Selectors

From: Ivan Herman via GitHub <sysbot+gh@w3.org>
Date: Mon, 25 Jan 2016 10:01:50 +0000
To: public-annotation@w3.org
Message-ID: <issue_comment.created-174457436-1453716108-sysbot+gh@w3.org>
Hey @hugomanguinhas,

> @iherman, about the domain for oa:hasSelector, I was not suggesting 
to define it using a formal language, just make a note in the spec….

I understand, but I am not sure it is really satisfactory if we keep 
to a formal language like RDF and with a formal vocabulary thereof...

> btw, is there such formal definition in RDFS or perhaps OWL?

Not for RDFS afaik. In OWL, yes there is. It is possible to define the
 union of classes. Taking the example from the OWL2 Primer[1], one can

:Parent owl:equivalentClass [
   rdf:type     owl:Class ;
   owl:unionOf  ( :Mother :Father )
 ] .

meaning that if there is definition that says ``ex:prop rdfs:domain 
:Parent``, and there is a triple ``x ex:prop y`` then the system can 
deduce that either ``x rdf:type :Mother`` or ``x rdf:type :Father`` is
 a valid triple. The caveat is that this class cannot be with the most
 "RDF-y" OWL profile, namely OWL-RL[2], ie, doing anything with it 
requires a more complex OWL reasoning...

However, all this can be hidden in the formal definition of the 
vocabulary that most of the users would not really use. But it can be 
there if needed. Ie, if we go down that line, we may decide to

1. Add the note as you say
2. Add the the formal definition in the namespace document for the RDF
 vocabulary (which I believe we will have to have)

[1] https://www.w3.org/TR/owl2-primer/#Complex_Classes
[2] https://www.w3.org/TR/owl2-profiles/#OWL_2_RL

> but, just a note that the domain could just be open without the need
 to prescribe either oa:SpecificResource or oa:Selector as 
> for the discussions on the stating the @type explicitly or implicit 
(entailed by one of the properties), my concern is for data consumers 
that are not applying RDF technology and thus may be expecting the 
@type to help determine how they will interpret and process the 
remaining structure…

Yes, I understand that. However, the approach taken by RDF can be 
described in a general manner, too, without using the 'R' word: if, 
say, the "A" property is used, then the object, resp. the subject of 
that property is of a specific type. This is all that is needed, no 
need for a complex RDF technology. However...

> the @type may also play a important role for data 
consistency/validation as different clients/implementations may apply 
different modelling patterns but also may have miss-interpreted the 
spec and used it in a way that it is not expected... I would thus vote
 to keep it as much as possible even though it may become slightly 
more verbose.

...I think that, in another issue, we closed that argument by 
accepting the SHOULD as a compromise between MUST and MAY. I guess we 
can leave it at that for now. Implementers/users in the CR phase will 
tell us if that is fine.

> Finally, I would add as another cons for the solution I proposed, 
that it would require twice the nesting (because of the additional 
SpecicResource in between) comparing with the simple nesting of 

Good point.



GitHub Notification of comment by iherman
Please view or discuss this issue at 
 using your GitHub account
Received on Monday, 25 January 2016 10:01:55 UTC

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