Re: oa:equivalent not yet in core-schema.xml

I agree strongly.  In my limited experience, even the carefully
crafted owl:sameAs can easily suck people into inconsistent data. My
guess is that there is a myriad of reasons and criteria for which one
might wish to impose equivalence relations on Annotations. I suspect
that  the most interesting ones are actually about domain knowledge,
and so belong---if at all---on Targets or Bodies, not on Annotation.

In trying to understand the core spec sec 2.4  I find myself confused
about the serialization recommendations independently(?) of
oa:equivalent. I will make a separate posting.

Bob

On Wed, Aug 8, 2012 at 11:26 AM, Stian Soiland-Reyes
<soiland-reyes@cs.manchester.ac.uk> wrote:
> On Tue, Aug 7, 2012 at 8:33 PM, Robert Sanderson <azaroth42@gmail.com> wrote:
>> I'm not sure *how* it would be modeled though.
>>
>> A suggestion was raised to get rid of equivalent and recommend either
>> skos:exactMatch or skos:closeMatch.  How do people feel about these
>> three options?
>
> +1 to avoid yet another equivalence notion!
>
>
> However, what do we need it for? For mirroring annotations?
>
> I would question whether such annotations are equivalent or even close
> match - because it could have later change upstream or even where it
> is now.
>
> It is more like it has been derived? I would use prov:wasQuotedFrom
> from PROV-O (it's like a full quote), combined with prov:alternateOf
> to show that they were somewhat interchangeable at the time.
>
>
> In PAV we have pav:retrievedFrom (with pav:retrievedOn and
> pav:retrievedBy for details about when it was retrieved, by who)
>
>     <!-- http://purl.org/pav/retrievedFrom -->
>
>> The URI where a resource has been retrieved from.
>> Retrieval indicates that this resource has the same representation as the original resource. If the resource has been somewhat transformed, use pav:importedFrom instead.
>> The time of the retrieval should be indicated using pav:retrievedOn. The agent may be indicated with pav:retrievedBy.
>
> which sounds like a perfect fit for this purpose.  It is quite more specific.
>
>
> I've not yet gone through PAV to make it subclass/property PROV, but
> that should be doable. (although property chains might be needed for
> some of them!)
>
>
> --
> Stian Soiland-Reyes, myGrid team
> School of Computer Science
> The University of Manchester



-- 
Robert A. Morris

Emeritus Professor  of Computer Science
UMASS-Boston
100 Morrissey Blvd
Boston, MA 02125-3390

IT Staff
Filtered Push Project
Harvard University Herbaria
Harvard University

email: morris.bob@gmail.com
web: http://efg.cs.umb.edu/
web: http://etaxonomy.org/mw/FilteredPush
http://www.cs.umb.edu/~ram
===
The content of this communication is made entirely on my
own behalf and in no way should be deemed to express
official positions of The University of Massachusetts at Boston or
Harvard University.

Received on Wednesday, 8 August 2012 18:01:13 UTC