- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Wed, 16 Jan 2013 22:00:18 +0100
- To: <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. This is right. But others at W3C seem not to have trouble with it: http://www.w3.org/2011/rdfa-context/rdfa-1.1 (recognizes the importance of FOAF alongside PROV and others) http://www.w3.org/TR/void/ (uses FOAF for persons) http://www.w3.org/TR/vocab-org/ (same) And that's apparently also true for the vocabularies being developed as we speak. In fact the Government Linked Data group is planning to re-use foaf:Person as such for its people vocabulary: https://dvcs.w3.org/hg/gld/raw-file/default/people/index.html#what-is-a-person Of course this doesn't come as a surprise: in a way, with the skill and amount of work and time that the FOAF community (Dan and Libby of course, but others have contributed many comments and idea) has put into it, FOAF is now more mature than many (most?) official W3C vocabularies. Please also note that while its namespace doesn't look super official, it is in fact backed by more formal agreements: http://dublincore.org/documents/dcmi-foaf/ > > 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. +1. But that's fully compatible with re-using FOAF for other classes. I note that we're already re-using both FOAF and PROV vocabularies for properties anyway... The approach should be to re-use everything that can be re-used, and re-use the most visible vocabulary terms first. Btw just to clarify (again) I have nothing specifically against PROV's way of modeling persons. My point is that one shouldn't think of it for modeling persons in the first place, when there's a widely used vocabulary which is meant for that. Cheers, Antoine > > 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 21:00:48 UTC