- From: Robert Sanderson <azaroth42@gmail.com>
- Date: Wed, 16 Jan 2013 12:03:17 -0700
- To: Paolo Ciccarese <paolo.ciccarese@gmail.com>
- Cc: Antoine Isaac <aisaac@few.vu.nl>, public-openannotation@w3.org
An argument in favor of PROV: PROV is a recognized W3C standard, whereas FOAF is a de facto standard by benefit of being first to market. That said, an argument in favor of FOAF: You need prov:SoftwareAgent much less frequently than you would need foaf:Person. If you don't record type of the serializedBy agent, then you wouldn't need both namespaces, thus making it simpler. Of the choice between reusing prov:SoftwareAgent and minting oa:SoftwareAgent, I prefer re-use. Rob On Wed, Jan 16, 2013 at 10:03 AM, Paolo Ciccarese <paolo.ciccarese@gmail.com> wrote: > 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 >>> <mailto: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 <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>> >>> >>> >> 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 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://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/ >>> >>> 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/ >>> 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 19:03:46 UTC