+1
I slightly wonder whether owl:equivalentClass prov:Agent brings more,
or less, FOAF baggage to the table than does subclassing, and what the
impact of such a choice is. Ditto for the other classes that might
overlap FOAF. I assume this issue was hashed out in PROV in the case
of comparison with dct...
Bob
On Wed, Jan 16, 2013 at 11:06 AM, Paolo Ciccarese
<paolo.ciccarese@gmail.com> wrote:
> I don't mind that for general consistency.
>
> Paolo
>
>
> On Wed, Jan 16, 2013 at 11:05 AM, Robert Sanderson <azaroth42@gmail.com>
> wrote:
>>
>> We could use those three classes? So prov:Person, prov:Organization,
>> prov;softwareAgent plus the other properties from foaf ?
>> That seems more consistent than the current situation.
>>
>> Opinions?
>>
>> Rob
>>
>> On Wed, Jan 16, 2013 at 7:34 AM, Stian Soiland-Reyes
>> <soiland-reyes@cs.manchester.ac.uk> wrote:
>> > PROV defines prov:SoftwareAgent [1] which might be appropriate. There
>> > are also prov:Organization and prov;Person.
>> >
>> > In the PROV-Dublin Core Terms mapping we make dct:Agent
>> > owl:equivalentClass prov:Agent. I think it should also be equivalent
>> > to at foaf:Agent, but we've not formally stated that anywhere.
>> >
>> >
>> >
>> >
>> > [1] http://www.w3.org/TR/prov-o/#SoftwareAgent
>> > [2] http://www.w3.org/TR/prov-dc/
>> >
>> > On Fri, Jan 11, 2013 at 3:37 PM, Robert Sanderson <azaroth42@gmail.com>
>> > wrote:
>> >>
>> >> Hi Bob, Paolo,
>> >>
>> >> Yes, we had the exact same discussion last week :) The conclusion was
>> >> that
>> >> the inference of Agent-ness can be drawn based on the range of
>> >> oa:annotatedBy / oa:serializedBy, or the domain of the various foaf
>> >> properties. So requiring the assertion to be explicit was unnecessary.
>> >>
>> >> The options seem to be:
>> >> * Status quo, but make it explicit in the description of the Provenance
>> >> Agents section
>> >> * Create our own SoftwareAgent subClass of foaf:Agent
>> >> * Convince Dan to add one to foaf
>> >>
>> >> Dan?
>> >>
>> >> Rob
>> >>
>> >> On Fri, Jan 11, 2013 at 7:57 AM, Paolo Ciccarese
>> >> <paolo.ciccarese@gmail.com>
>> >> wrote:
>> >>>
>> >>> Hi Bob,
>> >>> we have been discussing that issues when we picked that type
>> >>> and we felt a little uncomfortable as well.
>> >>>
>> >>> In the past, personally, I've been extending FOAF with some classes
>> >>> and
>> >>> properties.
>> >>> That is the other option I see. It would be our class though.
>> >>>
>> >>> Paolo
>> >>>
>> >>>
>> >>> On Fri, Jan 11, 2013 at 1:10 AM, Bob Morris <morris.bob@gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> I guess this issue is in the current core also.
>> >>>>
>> >>>> In http://www.openannotation.org/spec/future/core.html#ProvAgents it
>> >>>> is proposed that dctypes:Software be used to type a software agent.
>> >>>> One problem is that dctypesSoftware is not a subtype of foaf:Agent,
>> >>>> thereby requiring(?) that a foaf:Agent type also be asserted on any
>> >>>> Agent of type dctype:Software.
>> >>>>
>> >>>> I don't find this inherently improper, but I'm uncomfortable about an
>> >>>> asymmetry between the Person and Software cases. I don't have a
>> >>>> better
>> >>>> idea though, and wonder why the FOAF community hasn't offered such a
>> >>>> subclass.
>> >>>>
>> >>>> We also would often need to have Software as the object of
>> >>>> oa:annotatedBy. In addition to humans, we have Kepler workflows
>> >>>> producing annotations autonomously.
>> >>>>
>> >>>> Bob Morris
>> >>>>
>> >>>> --
>> >>>> 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.
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Dr. Paolo Ciccarese
>> >>> http://www.paolociccarese.info/
>> >>> Biomedical Informatics Research & Development
>> >>> Instructor of Neurology at Harvard Medical School
>> >>> Assistant in Neuroscience at Mass General Hospital
>> >>> +1-857-366-1524 (mobile) +1-617-768-8744 (office)
>> >>>
>> >>> CONFIDENTIALITY NOTICE: This message is intended only for the
>> >>> addressee(s), may contain information that is considered
>> >>> to be sensitive or confidential and may not be forwarded or disclosed
>> >>> to
>> >>> any other party without the permission of the sender.
>> >>> If you have received this message in error, please notify the sender
>> >>> immediately.
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Stian Soiland-Reyes, myGrid team
>> > School of Computer Science
>> > The University of Manchester
>>
>
>
>
> --
> Dr. Paolo Ciccarese
> http://www.paolociccarese.info/
> Biomedical Informatics Research & Development
> Instructor of Neurology at Harvard Medical School
> Assistant in Neuroscience at Mass General Hospital
> +1-857-366-1524 (mobile) +1-617-768-8744 (office)
>
> CONFIDENTIALITY NOTICE: This message is intended only for the addressee(s),
> may contain information that is considered
> to be sensitive or confidential and may not be forwarded or disclosed to any
> other party without the permission of the sender.
> If you have received this message in error, please notify the sender
> immediately.
--
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://wiki.filteredpush.orghttp://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.