W3C home > Mailing lists > Public > public-openannotation@w3.org > January 2013

Re: whine about dctypes:Software

From: Paolo Ciccarese <paolo.ciccarese@gmail.com>
Date: Wed, 16 Jan 2013 12:03:59 -0500
Message-ID: <CAFPX2kC8dE6ccu5VuXBtRhRFBC_7Z9EVCWaicsAnKzZVO-OEdw@mail.gmail.com>
To: Antoine Isaac <aisaac@few.vu.nl>
Cc: public-openannotation@w3.org
Antoine,
FOAF has always been our first pick, we are on the same page for that.
The issue came up when talking about Software Agents, what do we do there?

We can certainly say:
:paolo a foaf:Person, prov:Agent;

But for a software agent we would have:
:tool a prov:SoftwareAgent
with no link to FOAF as PROV does not link them.
Are we happy with this?

The other option would be:
:tool a oa:SoftwareAgent (subclass of foaf:Agent).

Paolo

On Wed, Jan 16, 2013 at 11:52 AM, Antoine Isaac <aisaac@few.vu.nl> wrote:

> I'd rather go for FOAF whenever possible (Agent, Person and Organization)
> and pick what's not there from other vocabularies (PROV is of course a good
> one).
>
> I don't want to downplay PROV, but FOAF is better-known, probably users
> will have heard about it even before they hear that OA could be a good
> ontology for their needs. It It would sub-optimal to present them with
> classes from other vocabularies. More than having a nice set of classes
> that come from the same vocabulary.
>
> Besides, FOAF is greatly avoiding semantic over-commitment. Nothing can
> possibly beat a definition like 'Something is a Person if it is a person.
> We don't nitpic about whether they're alive, dead, real, or imaginary.'!
>
> I'm not saying that PROV would have a definition that doesn't match very
> well its own purposes - and perhaps the prov:Person is strictly equivalent
> to foaf:Person. But usually PROV is quite tight semantically (which is also
> good for their case), and I would hate that users spend 10 minutes checking
> the definition there, while there wouldn't have been any issue with FOAF.
> In fact I take it as a good hint that even I don't feel like checking it
> right now: you'll probably know by now that I love checking models in
> details ;-)
>
> Oh, OK, I've checked. I've even found that the PROV doc has something like
> that:
> :derek
>    a foaf:Person, prov:Agent;
> at http://www.w3.org/TR/prov-o/
>
> And I don't find an equivalent class mapping between foaf:Person and
> prov:Person at http://www.w3.org/ns/prov-o
>
> Antoine
>
>
>  I don't mind that for general consistency.
>>
>> Paolo
>>
>> On Wed, Jan 16, 2013 at 11:05 AM, Robert Sanderson <azaroth42@gmail.com<mailto:
>> 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<soiland-reyes@cs.manchester.ac.uk><mailto:
>> soiland-reyes@cs.**manchester.ac.uk <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<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 <mailto: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 <mailto:paolo.ciccarese@gmail.**com<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 <mailto: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<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 <mailto:morris.bob@gmail.com>
>>
>>      >>>> web: http://efg.cs.umb.edu/
>>      >>>> web: http://etaxonomy.org/mw/**FilteredPush<http://etaxonomy.org/mw/FilteredPush>
>>      >>>> http://www.cs.umb.edu/~ram <http://www.cs.umb.edu/%7Eram>
>>
>>      >>>> ===
>>      >>>> 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/<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 <tel:%2B1-857-366-1524> (mobile) +1-617-768-8744<tel:%2B1-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/ <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.
>>
>
>
>


-- 
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.
Received on Wednesday, 16 January 2013 17:04:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 16 January 2013 17:04:28 GMT