trdf-prv-vocab-users Mailing List for tRDF
Status: Pre-Alpha
Brought to you by:
hartig
You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
(17) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
(25) |
Jul
(8) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
(1) |
Mar
(12) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
|
Dec
|
From: Olaf H. <ha...@in...> - 2013-10-31 21:54:39
|
Hi Jasbir, On Thursday 31 October 2013 21:31:27 Luthera, Jasbir wrote: > Hi Olaf > > You are right on all points. However, no matter what the ontology tool is, > the import statement below, by specification, is http endpoint. > > files.rdf line 12: > > <owl:imports rdf:resource="http://purl.org/net/provenance/ns#"/> > > There is no spec defined by w3c (that I am aware of) which define the > transmission protocol: > > rdf+xml://purl.org/net/provenance/ns# Of course not. The transmission protocol is HTTP. However, to retrieve an RDF/XML representation of the resource identified by URI http://purl.org/net/provenance/ns (i.e., of our vocabulary), the HTTP client (e.g., curl, Protege, a standard Web browser) needs to ask for RDF/XML by specifying the corresponding mime type (i.e., application/rdf+xml) in the Accept header field of the HTTP request. Alternatively, the client may omit specifying an Accept header field, in which case our Web server is configured to default to the RDF/XML representation. If, however, the client specifies the mime type for HTML documents (i.e., text/html) in the Accept header (which is what a standard browser does), then our server responds with an HTML representation. Best, Olaf > -J > > -----Original Message----- > From: Olaf Hartig [mailto:ha...@in...] > Sent: Thursday, October 31, 2013 1:59 PM > To: trd...@li... > Cc: Luthera, Jasbir > Subject: Re: [trdf-prv-vocab-users] FW: error on reference to prov voc core > ontology ns > > Hi, > > The W3C suggests to publish RDF vocabularies using HTTP content negotiation > (see: http://www.w3.org/TR/swbp-vocab-pub/ ), and that is what we do for > publishing the Provenance Vocabulary. > > If you execute the curl command as given in my earlier mail, you will see > that curl retrieves the RDF/XML document and not the Web page. This is > because the curl command requests an RDF/XML representation. If you put the > URI in a standard Web browser, the browser will retrieve the Web page > because the browser requests HTML (instead of RDF/XML). > > So, either Protege does not use HTTP content negotiation at all, or there is > a bug in how Protege uses content negotiation. However, I think the problem > is not on our side. > > Anyways, if you want to load the RDF/XML document directly, the URI for that > is: http://trdf.sourceforge.net/provenance/ns.rdf > > By the way, for the modules (i.e., types, files, integrity) we do not have > an HTML representation (aka Web page) and, thus, our Web server always > responds with the corresponding RDF/XML document. > > I hope this helps, > Olaf > > On Thursday 31 October 2013 19:12:44 Luthera, Jasbir wrote: > > Try to open the following in the browser: > > > > http://purl.org/net/provenance/types > > http://purl.org/net/provenance/files > > http://purl.org/net/provenance/integrity > > > > All of above download an rdf file, as expected. > > > > However, if you load say files.rdf in Protégé, there is that error > > message that I indicated because line 12 has the following statement > > > > <owl:imports rdf:resource="http://purl.org/net/provenance/ns#"/> > > > > If you copy/paste that url into your browser, it does open up the > > website, that's why curl works. However, it should provide Provenance > > > Core Ontology Namespace, as also, indicated in the following URL: > http://sourceforge.net/apps/mediawiki/trdf/index.php?title=Provenance_Vocabu > lary > > -----Original Message----- > > From: Luthera, Jasbir [mailto:Jas...@ea...] > > Sent: Thursday, October 31, 2013 12:13 PM > > To: Olaf Hartig; trd...@li... > > Subject: *****THIS MESSAGE MAY NOT BE VALID ****** > > > > Ubuntu, Protégé latest version 4.3.0 build 304 > > > > -----Original Message----- > > From: Olaf Hartig [mailto:oh...@uw...] > > Sent: Thursday, October 31, 2013 12:11 PM > > To: trd...@li... > > Cc: Luthera, Jasbir > > Subject: Re: [trdf-prv-vocab-users] FW: error on reference to prov voc > > core ontology ns > > > > Dear Jasbir, > > > > There seems to be a problem with the software that you are using. > > Resolving the URI for the Provenance Vocabulary (i.e. the URI: > > http://purl.org/net/provenance/ns ) works fine. I have just checked: > > with the program "curl" I have requested the RDF/XML serialization of > > the vocabulary using the following command: > > > > curl -L -H "Accept: application/rdf+xml" > > http://purl.org/net/provenance/ns > > > > This worked perfectly fine. > > > > What system is it with which you are trying to load the vocabulary? > > > > Best, > > Olaf > > > > On Thursday 31 October 2013 18:16:56 Luthera, Jasbir wrote: > > > How can I resolved the following error? > > > > > > The system couldn't locate the ontology: > > > http://purl.org/net/provenance/ns#<http://purl.org/net/provenance/ns > > > > > > > > > Thanks in advance for your replies. > > > > > > -J > > > > ---------------------------------------------------------------------- > > ------ > > -- Android is increasing in popularity, but the open development > > platform that developers love is also attractive to malware creators. > > Download this white paper to learn more about secure code signing > > practices that can help keep Android apps secure. > > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c > > lktrk _______________________________________________ > > trdf-prv-vocab-users mailing list > > trd...@li... > > https://lists.sourceforge.net/lists/listinfo/trdf-prv-vocab-users |
From: Olaf H. <ha...@in...> - 2013-10-31 20:58:54
|
Hi, The W3C suggests to publish RDF vocabularies using HTTP content negotiation (see: http://www.w3.org/TR/swbp-vocab-pub/ ), and that is what we do for publishing the Provenance Vocabulary. If you execute the curl command as given in my earlier mail, you will see that curl retrieves the RDF/XML document and not the Web page. This is because the curl command requests an RDF/XML representation. If you put the URI in a standard Web browser, the browser will retrieve the Web page because the browser requests HTML (instead of RDF/XML). So, either Protege does not use HTTP content negotiation at all, or there is a bug in how Protege uses content negotiation. However, I think the problem is not on our side. Anyways, if you want to load the RDF/XML document directly, the URI for that is: http://trdf.sourceforge.net/provenance/ns.rdf By the way, for the modules (i.e., types, files, integrity) we do not have an HTML representation (aka Web page) and, thus, our Web server always responds with the corresponding RDF/XML document. I hope this helps, Olaf On Thursday 31 October 2013 19:12:44 Luthera, Jasbir wrote: > Try to open the following in the browser: > > http://purl.org/net/provenance/types > http://purl.org/net/provenance/files > http://purl.org/net/provenance/integrity > > All of above download an rdf file, as expected. > > However, if you load say files.rdf in Protégé, there is that error message > that I indicated because line 12 has the following statement > > <owl:imports rdf:resource="http://purl.org/net/provenance/ns#"/> > > If you copy/paste that url into your browser, it does open up the website, > that's why curl works. However, it should provide Provenance Core Ontology > Namespace, as also, indicated in the following URL: > > http://sourceforge.net/apps/mediawiki/trdf/index.php?title=Provenance_Vocabulary > > > -----Original Message----- > From: Luthera, Jasbir [mailto:Jas...@ea...] > Sent: Thursday, October 31, 2013 12:13 PM > To: Olaf Hartig; trd...@li... > Subject: *****THIS MESSAGE MAY NOT BE VALID ****** > > Ubuntu, Protégé latest version 4.3.0 build 304 > > -----Original Message----- > From: Olaf Hartig [mailto:oh...@uw...] > Sent: Thursday, October 31, 2013 12:11 PM > To: trd...@li... > Cc: Luthera, Jasbir > Subject: Re: [trdf-prv-vocab-users] FW: error on reference to prov voc core > ontology ns > > Dear Jasbir, > > There seems to be a problem with the software that you are using. Resolving > the URI for the Provenance Vocabulary (i.e. the URI: > http://purl.org/net/provenance/ns ) works fine. I have just checked: with > the program "curl" I have requested the RDF/XML serialization of the > vocabulary using the following command: > > curl -L -H "Accept: application/rdf+xml" http://purl.org/net/provenance/ns > > This worked perfectly fine. > > What system is it with which you are trying to load the vocabulary? > > Best, > Olaf > > On Thursday 31 October 2013 18:16:56 Luthera, Jasbir wrote: > > How can I resolved the following error? > > > > The system couldn't locate the ontology: > > http://purl.org/net/provenance/ns#<http://purl.org/net/provenance/ns> > > > > Thanks in advance for your replies. > > > > -J > > ---------------------------------------------------------------------------- > -- Android is increasing in popularity, but the open development platform > that developers love is also attractive to malware creators. Download this > white paper to learn more about secure code signing practices that can help > keep Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > _______________________________________________ > trdf-prv-vocab-users mailing list > trd...@li... > https://lists.sourceforge.net/lists/listinfo/trdf-prv-vocab-users |
From: Luthera, J. <Jas...@ea...> - 2013-10-31 19:36:05
|
Try to open the following in the browser: http://purl.org/net/provenance/types http://purl.org/net/provenance/files http://purl.org/net/provenance/integrity All of above download an rdf file, as expected. However, if you load say files.rdf in Protégé, there is that error message that I indicated because line 12 has the following statement <owl:imports rdf:resource="http://purl.org/net/provenance/ns#"/> If you copy/paste that url into your browser, it does open up the website, that's why curl works. However, it should provide Provenance Core Ontology Namespace, as also, indicated in the following URL: http://sourceforge.net/apps/mediawiki/trdf/index.php?title=Provenance_Vocabulary -----Original Message----- From: Luthera, Jasbir [mailto:Jas...@ea...] Sent: Thursday, October 31, 2013 12:13 PM To: Olaf Hartig; trd...@li... Subject: *****THIS MESSAGE MAY NOT BE VALID ****** Ubuntu, Protégé latest version 4.3.0 build 304 -----Original Message----- From: Olaf Hartig [mailto:oh...@uw...] Sent: Thursday, October 31, 2013 12:11 PM To: trd...@li... Cc: Luthera, Jasbir Subject: Re: [trdf-prv-vocab-users] FW: error on reference to prov voc core ontology ns Dear Jasbir, There seems to be a problem with the software that you are using. Resolving the URI for the Provenance Vocabulary (i.e. the URI: http://purl.org/net/provenance/ns ) works fine. I have just checked: with the program "curl" I have requested the RDF/XML serialization of the vocabulary using the following command: curl -L -H "Accept: application/rdf+xml" http://purl.org/net/provenance/ns This worked perfectly fine. What system is it with which you are trying to load the vocabulary? Best, Olaf On Thursday 31 October 2013 18:16:56 Luthera, Jasbir wrote: > How can I resolved the following error? > > The system couldn't locate the ontology: > http://purl.org/net/provenance/ns#<http://purl.org/net/provenance/ns> > > Thanks in advance for your replies. > > -J ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ trdf-prv-vocab-users mailing list trd...@li... https://lists.sourceforge.net/lists/listinfo/trdf-prv-vocab-users |
From: Olaf H. <oh...@uw...> - 2013-10-31 19:34:11
|
Dear Jasbir, There seems to be a problem with the software that you are using. Resolving the URI for the Provenance Vocabulary (i.e. the URI: http://purl.org/net/provenance/ns ) works fine. I have just checked: with the program "curl" I have requested the RDF/XML serialization of the vocabulary using the following command: curl -L -H "Accept: application/rdf+xml" http://purl.org/net/provenance/ns This worked perfectly fine. What system is it with which you are trying to load the vocabulary? Best, Olaf On Thursday 31 October 2013 18:16:56 Luthera, Jasbir wrote: > How can I resolved the following error? > > The system couldn't locate the ontology: > http://purl.org/net/provenance/ns#<http://purl.org/net/provenance/ns> > > Thanks in advance for your replies. > > -J |
From: Luthera, J. <Jas...@ea...> - 2013-10-31 19:12:54
|
Ubuntu, Protégé latest version 4.3.0 build 304 -----Original Message----- From: Olaf Hartig [mailto:oh...@uw...] Sent: Thursday, October 31, 2013 12:11 PM To: trd...@li... Cc: Luthera, Jasbir Subject: Re: [trdf-prv-vocab-users] FW: error on reference to prov voc core ontology ns Dear Jasbir, There seems to be a problem with the software that you are using. Resolving the URI for the Provenance Vocabulary (i.e. the URI: http://purl.org/net/provenance/ns ) works fine. I have just checked: with the program "curl" I have requested the RDF/XML serialization of the vocabulary using the following command: curl -L -H "Accept: application/rdf+xml" http://purl.org/net/provenance/ns This worked perfectly fine. What system is it with which you are trying to load the vocabulary? Best, Olaf On Thursday 31 October 2013 18:16:56 Luthera, Jasbir wrote: > How can I resolved the following error? > > The system couldn't locate the ontology: > http://purl.org/net/provenance/ns#<http://purl.org/net/provenance/ns> > > Thanks in advance for your replies. > > -J |
From: Luthera, J. <Jas...@ea...> - 2013-10-31 18:49:12
|
How can I resolved the following error? The system couldn't locate the ontology: http://purl.org/net/provenance/ns#<http://purl.org/net/provenance/ns> Thanks in advance for your replies. -J |
From: Luthera, J. <Jas...@ea...> - 2013-10-31 18:23:12
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <!-- Branding: You'll probably want to set the title. --> <title>Proofpoint Encryption</title> </head> <BODY style="font:normal 11px Arial;background-color:#FFFFFF; margin:0px; padding:0; height:100%; width:100%"> <TABLE BORDER=0 CELLPADDING=10 CELLSPACING=0 WIDTH="100%" HEIGHT="100%"> <form method="post" name="theForm" target=_top action="https://securemail.earlywarning.com/formpostdir/safeformpost.aspx"> <input type="hidden" name="rcptData" value="PENvdXJpZXJPcHRpb25EYXRhPgogIDx2ZXJzaW9uPgogICAgMQogIDwvdmVyc2lvbj4KICA8c3Vi amVjdD4KICAgIEdGSENIQ0dQSENDQUdQR09DQUhDR0ZHR0dGSENHRkdPR0RHRkNBSEVHUENBSEFI Q0dQSEdDQUhHR1BHRENBR0RHUEhDR0ZDQUdQR09IRUdQR01HUEdISEpDQUdPSEQKICA8L3N1Ympl Y3Q+CiAgPHJlcGx5LXRvPgogICAgSmFzYmlyLkx1dGhlcmFAZWFybHl3YXJuaW5nLmNvbQogIDwv cmVwbHktdG8+CiAgPHJlcGx5LWZyb20+CiAgICB0cmRmLXBydi12b2NhYi11c2Vyc0BsaXN0cy5z b3VyY2Vmb3JnZS5uZXQKICA8L3JlcGx5LWZyb20+CiAgPGN1c3RvbWVyLUlEPgogICAgUUM6R0ZH QkhDR01ISkhIR0JIQ0dPR0pHT0dIRlBIQUhDR1BHRUhGR0RIRUdKR1BHT0NOSEdHTgogIDwvY3Vz dG9tZXItSUQ+CiAgPGJyYW5kaW5nLUlEPgogICAgMQogIDwvYnJhbmRpbmctSUQ+CiAgPHJlcGx5 LWVuYWJsZWQ+CiAgICB0cnVlCiAgPC9yZXBseS1lbmFibGVkPgogIDxyZXBseS1hbGwtZW5hYmxl ZD4KICAgIHRydWUKICA8L3JlcGx5LWFsbC1lbmFibGVkPgogIDxpbmNsdWRlLW9yaWdpbmFsPgog ICAgdHJ1ZQogIDwvaW5jbHVkZS1vcmlnaW5hbD4KICA8cmVwbHktdG8tY2MtZmllbGQtZW5hYmxl ZD4KICAgIHRydWUKICA8L3JlcGx5LXRvLWNjLWZpZWxkLWVuYWJsZWQ+CiAgPHJsZnNkPgogICAg dHJ1ZQogIDwvcmxmc2Q+CiAgPHJsZnJkPgogICAgdHJ1ZQogIDwvcmxmcmQ+CiAgPHJsZmFkPgog ICAgZmFsc2UKICA8L3JsZmFkPgogIDxybGZpZD4KICAgIGZhbHNlCiAgPC9ybGZpZD4KICA8Zm9y d2FyZC1lbmFibGVkPgogICAgdHJ1ZQogIDwvZm9yd2FyZC1lbmFibGVkPgogIDxmcmxmc2Q+CiAg ICB0cnVlCiAgPC9mcmxmc2Q+CiAgPGZybGZyZD4KICAgIHRydWUKICA8L2ZybGZyZD4KICA8ZnJs ZmFkPgogICAgZmFsc2UKICA8L2ZybGZhZD4KICA8ZnJsZmlkPgogICAgZmFsc2UKICA8L2ZybGZp ZD4KICA8aW5pdGlhdGUtZW5hYmxlZD4KICAgIGZhbHNlCiAgPC9pbml0aWF0ZS1lbmFibGVkPgog IDxoaWRlLWNjLXRvLW1lPgogICAgZmFsc2UKICA8L2hpZGUtY2MtdG8tbWU+CiAgPGRlZmF1bHQt Y2MtdG8tbWU+CiAgICB0cnVlCiAgPC9kZWZhdWx0LWNjLXRvLW1lPgogIDxkaWdlc3Q+CiAgICB0 T3ZseXNJcllDTXR6d3VKTCs2cVZUOW8xZGNtOEhrczVQWlc3WXgwOVlqbi9XREdaWFFxUXc9PQog IDwvZGlnZXN0Pgo8L0NvdXJpZXJPcHRpb25EYXRhPg== "> <input type="hidden" name="rcptLocale" value="enus"> <input type="hidden" name="msg0" value="U2lHYUJhUXo3SDxzZWN1cmUtZG9jIHhtbG5zPSdodHRwOi8vc2lnYWJhLmNvbS8yMDAxLzMvY29t bW9uL2RvY3VtZW50JyB2PSI3IiBtdj0iMyIgcnY9IjEiIGtzVVJMPSJodHRwOi8vbG9jYWxob3N0 OjgwODAva3Mva3MiIHR5PSJTU01BSUwiIGlkPSI1ODdjY2M1Mi1hOThmLTRjZTEtYTYwOS1jOTZh NGYxMzg4NWIiIGY9IkJJTkFSWSIgbGVuPSI1MDYxIiBjdD0iYXBwbGljYXRpb24vb2N0ZXQtc3Ry ZWFtIj48ZW5jcnlwdGVkLWRhdGEgZW49IkJhc2U2NCIgY2k9IkFFUy0yNTYiIGNvPSJHemlwIi8+ PHNpZ25hdHVyZS1kYXRhIGVuPSJCYXNlNjQiIGNvPSJHemlwIj5INHNJQUFBQUFBQUFBS1ZVMjNL aVFCQjkzNitneUtNRkRKZUJ3UUtyREpyRU5acEVZbUo4RzJZR1JSRTJYRFRtNnhlOFluU3JOcnN2 VkUwemZjN3AwOTFqdWNFa3dsbWVNTzVqRVVhcHpVK3o3RmRka2xhcmxiaFN4VGlaU0FvQVFBS21W RnlnYVRDNTRocy9PTTRxRXhudFJINWNIb3VBZzZNNENnZ09nMCtjQlhIVVk5azBwbHd6bk1SSmtF MFhsNkNmQjF0MFp5QVU2QUtSdFVnb0F6SlFkTDVoU1pjeGQ0UUg2WC9EOUxVSVJtaUtoWFNLRmJo aCtnSzJveGd3bnlVc0lvd2JEam8yZjdYQVVlQ3pOT08zLzRzYnp3bU9VajlPRnVrK1ZBMytYL1VI bUFPYmRFNW50WUpKb2VoZlBOaFhmeFMreFhyQlljNGFvVDRaazVlbitkMndmWGZiRGRQd01YVldF M285anZHMFg0dTY4NXUxOGlSTjdxSTFzaTJwbW5sUVc1VzJjMVE2V0xxWkl1bDBqSTQ5M1NLdFIr dWExRVpQTjgwNEg5NjZUbWR3ZmZ1U1BreTE1VHJ2dWJvNjc0N2hCNnE1Tk9pUDI2L21wek9MSHA2 dnc1ODNzcExXNWluOFpSb2pCZmVERDdYYkRHZlI2MUliTzFMVHRpdjlQa2kydW14ZEdlZmlkRnBO MjJtNXphL1Iwck40Z1lQb0VTZDR3VEtXVk9hZytOa3ZndFRKa3lYajhpU3krZUpUandOYWwwVkZS Qm9RWlFBMEtLcWlMQnBseDQvWEt3VFNueG1zeDl3TEExS29PbUVkY2N0U3BNM0xtdUlaSGxKMXBn RktEUlVRYXVnS0JRYjJzQThRVWxRQ1BXcENqTEVPbUtKUW92dXlEakZDRkp1TXNGTFQ2QVQ2YlEr dHk1QVJVOVk5SFJXSlVDdmdEZUlEQXJBdU00Z1E4NWhQTUdTUWFESUNCUjREa0JoWXcxQkZSZHFt M0xkcWxXZWxXTklGeXkycGV0NmN0azJ6SHJ3Wkk5bitHZHROdGRYYmJldzNuamN1b0RaL3Z1bkh0 eUJQQXB0MzNWNnpjMStIeUNDRVFFWEFKdklGalRCWktLdzBCV0xxV1BObEZTSG9uVy9ZYmx2eE43 ZFY1azk2VWQyNWVPMjlxNjBtY2Q5SHJXVk9sZnZXYk5qUjcydk9Zbmg1T3kvdjU5bUdsb0c5aDF2 SHR6NVhuOHpHYjR5c1FDTkdCZ0FBPC9zaWduYXR1cmUtZGF0YT48aWRlbnRpdHktZGF0YSBlbj0i QmFzZTY0IiBjbz0iR3ppcCI+SDRzSUFBQUFBQUFBQU8xWFdYUGlPQkIrbjE5Qk1TKzdRNEVsMi9K QkFiV2NFNDRraEFBSnZNbVdiQnlNVFdSejVkZXZ6R0VjSnV6c2JwTGEzVnFxZURDdDF0ZUhQblcz "> <input type="hidden" name="msg1" value="Q2pkNFJzdEJRRm5vK0Y1cVBYTzlvSmllaE9FOEx3aGVrQXZFbVp2em1TMUVIK25TbDFTcTBLeVZG c3pMejZnNXdaNFR6SVF1ODMxcjdqdGVtR280YmtoWnFzbzI4OUF2ZDV1LzZZMjZoSlJhSmR2UVJD VXJLMGpLVmlwbFBRczF2YVpyZWwydUttSWVXbnBCNExCYjlDQllVRmI2T0hTT3ZJT00wR3M0cENV UlFDa0xRVmFDZlNqbG9aZ0hvcGdGS0E5QVFkZ3FSSnJsQlhHb1o5SmdHK3kzZ25BVVJNdEQ3RHJF Q1RkTmozdTB4RzRrNU9JYlA2eFF5MmV2amNBOFVwTkdqbHJ4cnJMRmNaS2JSSGppV2F3VW1SZmVz czk5RGljOEFMeUhqZjcyTjNOYTZ2aTI0MFVSN1AvdmxnZjgwSyt3UjF4YWVuK09FMkI3NDY2REE1 NnM5ME1ma0hhNGRjK005bk95MXZ3WmRyd1N4Y3pkckREekhNL09tZjZzSVB5Z3N0dlpvODhMR2tR WmpEMG9DRWZoVHFsSnFCZnl2UGI5S2QxdmpJeFdhL2ZsTnQzd3JDL295U1ZaclZhNWxiUzlJeUlB UUFDNndCVkk0TmhmMHdlQWlIbGJWN3FZOGZ2R3pRWEhwWWdBWEVpcUM3YWtLYzYyWWpxaW5PK1FQ TXlKT1UwR09RaUFqSEpTRHViVWRJbFRJVlpQR0JET1d5aDBGNGJybUR5QVYxWWZVOHNvbm1JYWFx cU9FRFlzREtDbWFKYUJGUWdzUUV4RlFxWXFXZ2lvb3FoU2FrSUpRRU5XUkVzV1JTSnAySVRJUXJv YytmVDRDbnAwZ05ZTUJTaUtUb0JrUUNRYXhPSjJSQlZwaEFlRUNOR3dwUUZGVTJYZEFJZ3Z5ckts UXFBcHBtWEpBQnRrRys0b0dlVVBvZkR6VHA3Ty9oeUZOdzZ5Y08vWUhnNFhqSExsd3luR1oxVGd3 cVpuK1FsanJ6RS9qQXMvNWNOSGNlSm52RGpQalJOK3lLS2hHcHFrVUJrUW9rckFKS29pRXFCaUEx dEEwMFRKUkFiUkVjWllBWlJUdzFRc3FDQ3NhUVRyMUtRLzhPTTFSeFNJcUtsRHhWQTB2aG5KM0lS cVdzQUVuSVlVYVJvMXFHVmlSSkVwUXcxd1RBbzRMYkdNa2FUeGJhY2NPY09UczF6Wkxaekt0cElq SHdwQ2tqeHhSZkhvYXNCcDV1NHJOOHdDZGR0VFFCNGdjS2pjQ2JWdDdVNlc2U01uL3pLVnRsc3BT WEsyVU1XZTd6a21idzR2T0NxQTF6U2MrQ1JWZG0yZk9lRms5aFo4djdlelVPMWx1WVdzQ1dVdkd3 a2dFSlVvdFc5anhpYmpBUDZNcmROUXFFa0NuQTBtV0VSYld5ZGdzWkVldFNpTHVtOXEwR3NXMDEv WDI0NUMyUys1bkhENC9ab3N0MzJHdllDMzJObnJRaHVMMzVlU0dDYkpvTGRNRm1xT3pkdkwzMG5O SVNsSjkzZG9PNTQ2VjQ5M1RLZ2h1QlRSamFSWUloVE4xazJYWEpXdFNxMGR1QzFtTGZEbU1kUnVy NHU4Q0NSMkpudEd3cjBqOCtOc0o3bWZaTnJ4MEhlSU5WL0Q0ejZGQTZreGJ2VFVaVzA0MGRHZERO cVp5WWplbXZlVG03NTRyL1RDc2QyOHQ0UGdwZkhRYUU5bnE0N05CSWxwVFpjK2pPdnJjZTNxZnRt K1kvVWEyTUR5OVVPNVdFd1FJbG5jVHlyMUczVzZjT2FlLzdUd2ZrelovZU9pZTY3a2ZtSkQvc1NX ZktiWW5pbTFwNFgyVlpsTkhIZnB5eTYzOGRPRUMrcFJRM2ZwakRmMmYrNmhrZ2VYcDhvSFBGVnFk "> <input type="hidden" name="msg2" value="RTQ5RXR4Nm4vS1dQS0p2OC9PU2VCUk5nNnpENlhaQ0lGNXcrU3dUUFI5MmRSaUtlNUZIdyswWGI5 bkhTWEZLTjFsT3l5WDN6aUV4aHV2ekhqbnhnekRQaHhRZ1RBUCtpKzdLVWZ0QStiMFArMm5nNVRJ TFhHYUI5ODBDdHcrTksyTlJGMFlxdjJZQkc5Mk81czBXSmZYbDAzcjJQTTJzbmtlRzFIMzB4Y1Zr OWVtemdORHZENlUyZTI0NzlaSG9Qc0h5WTh0YTR2VUx5NUFCdHMxNlp0ME9wbklGQ1Vnb214MDBX cXF6OFVwMFdIQjlaOXdNUjArcmNENUNsanlvVklWaDVxblRneHZXOWkrendQOThGa2owL24vTkpB QXZrOEIvZVJJZzFLVTJ6MXlXQi9XdWNXQVB4Rkd3RWZqdUl1UVh5OEp1UU5PcFlHRThVVE1zcGht MTZUcWYreFpkbUZqL1FQdWtKNWVoNERJVWZNeFFZQk9YV2Nac1RESTJtMlJhdXJGdU8rWllXVDlr V3RPWHhsMTU0NFIySmZNOWVGbURUeDhLeEdWcjN0RjYzemU2UDN5RzA4R3F5K3BEUFh5RTNVR20w OUk2MXZCcWxIR3JqTlR1MmJ6NmhKbGFEcFgrZDVOMGJHcGxtczNCSEMyK2J5Qnp4aEp1YWRyUzdO ZWVLbmVYb2VBeUZNUkR3ZS9SbURQVnlod0FBQT09PC9pZGVudGl0eS1kYXRhPjwvc2VjdXJlLWRv Yz7yVA8JZiodADOpQX1XVLeuhIWGmHlVQjtTxgRNxLZkTZhTZERdAUVU0Yft8IAhDn9+Haswuycc IcDn7kF7bmvn/Af+HmQtyoJfsLos0MkLebZ+OkvgIwfxrBN9FVxP+3fDCmsHxCE4+uGYfh9J1B3D QV6STZfKfTQVhVzcIO0VuNBDmUEBEVbltdYXPcZO7S7yXVtdrP1nF/zLklJHgIw8ni2WHss3Agie jbClkKx3/UFvsczkwhm/JuIV3tKb2n1ncGDc9zvtzIY4+0gcqikrj0R74ZSrXZ+/T4pAaJlHnTQQ 3joqRY75xsPZfv/ursEmORB1FqfyxbSZx2D6N6tUXCM1q39t/lhcaAuqR1fTvE62T7T9kx2Hmr7m m+xtQX/TUbGj8TmLFs+Zeq55FxjhHVbOoXySkv18xUXSZRy8GRvS3civE+yemLx1cZz6bFpXdgf9 pZPQU1fGk9u65ziQJnHLBRNU3b9pUlb2AwH+STkAqeCfqT1buehaLPs3qgtDSJYhfmlQTfX/U5se BI3nyw7j8+EQTuDmJxnuHz5g79PLqR0fwhVBHi7zPDs+6BFEcpzt/ebhlrE4xTogQH/SIUwIyN5f O8skxbaMAsuCC6+2c88UP0dYLj4ITk/s8smsIJTuEY+Og6t8guyfGCVDyrV39lSAhYfNv3Hxg+4J Tt012DvbokAokO9Ea0mzUiQf4jjhriSCvOMHFJQXIQAEoxUVFPsm7iRAMqur5YLkuCVu2lmGB9bd Of8VoKIy5nvsCP/1zv9ANgT2GNForbLfB6XvZPJ38X6HqRMX99LDd4BUsZbv1Gw6AceBP7ugw6y9 UnmizDD5SFJSz484L46/yOUQfdhY/EnHps5QtngMpQhNPZhNrvGHljdJ6Xz08CsEyMo5KCpP2Stq z9gLoyrcOjI4SCsPrCjcQbj0Qp3dZvtBK4mw3aP/CaTACi81PPfnNt/1bCIA8YCP8uKFMJL25S5v IsuqshRyXFYkHTgEExKIXDPIYDmZeYEX6K5TUzogf1QqMftQxosQQhBGBKpg+FJc3dssgSP3W5fY Vy73OIjsZ4JEHjjgfmCypwDgjFJvARBBHFz9nsaI67/HWRtr6SatXLYkzJQr1knmXDlv8cXvYDyL "> <input type="hidden" name="msg3" value="xxEYJSLyLrfyoecVbDgiI7TUcXeDT1mJfKye340D23RdTCwB5OIZelmk2Frf1V9ZEg2Xs+0zWwnS 0842HI6gp4xLP7urs372HT75XZtEqDiakemd73PbjZVJL8j9EEKwLzH+81bLgq24olJZ7KUs3rRi Z+7nd0Zg0dyzsvOn2IMBhuTnwcKVjBRt1CP4oeYTL7i7RAvIYgQBz8K6Uir3daZt4vR73oJeYXg5 R/yqe0iH7OsZrUJzCcHEgmWLERWhRyDjKIeGstx3oyDsltpYVioiLr+u0eMAQeCa+AIJezrJeyGp 5d6y6VrhC9GD/Yv/nTRS60c3K94jeJZj9qsmkjH03vBG505NBX00xtJSaYKCbgnaiIYLJke7SD+v mydNC/0nc+nZjc2+biCbkM1S9E60fm+dzFu7Vd5iChOvpcRe8DkpJhT84cXnVrEfwznekEP8dWYO EBzEPIDDyFilSoJPh/ZdcBWcp2tPZ7qIa10T8Q8njggjp+yEnY+RDDLm5LLNS9N1PcpjzaI1Ta37 MKnOPEY8Kbod4V5PM1umqzzJqPtAKOVbCKjbaNBs52qOpyPzkvyLlLy0FoQFLsihk9UDWQm8Tn1q gruAvy2fdC5j6BZ3qlgko16ieJqk2Ft12RYFyLxJLQzjzhs+b9yUQU/LeYsOZVwuEOItlAMMgPBq df776QKgSzJzRoJk1z4bzNmRtsDxbeqh7yW+LX5JpgLZaYqrdoKPBRkRB4UK7Wd4RPdPjofpuiFh 8xmQv0D0IGaCuaKSBYx3WtTDF+Z6uw29uwy23wdjA5eeScnmBO/I7f8QRKQV9kRCKQ98IrMeEIkS B0gP5OcFyYNCw8biCAajV8jVFLVc97Th7zL7FtH84QCrcypOp0wcIE3aFsz1fHq80m0Mr+X1XXUz zQlB0KcOT9godrzP9cFo8h9eEuAz9fVJhXUHoM/PnGuuMB57o/LMi1GqXwL0/UEu/aUVVjsHJHAb MtrhQ3nMJTREIp1wMpZZjvOEkrZNQ4dPo/iiWGOpGagWouUC/FR08ppPa0M6rfaSsApwW6lIlun1 4RUQQWO3mwAFPIUPfOfuiKJw5ZSM4zCFcIYc94bR0Cs3mzExeLMdAw79/Xy5rjGg9Jm0bCP74x7u mEQ85p/kNNIko4tDTXsk0yOgJmRr6K5BmZqOiOjZL1CYW1RFWgBF8xS2bMLTxkKTPFVob2FRLIkd QIxY2aWqz6796j9wCQD1ywPBC8S2YvzXmbMpwJ5A/CT6GLK2vZ0WpwY8T7ZJvGpap2IGfm0uJiHc KbxskKDZ63ThhR1suwbt7iS3Ko1RgQIRsZY5l79rjdx+qK0Ih0NDhp0ApPMSXTUu2+stRSnZTbrP mDBP7fPiqFRLiEi0XJ0Y1XHsSqjP0Q5addtFBlLVLYWpchpjEb8VXgkG/JMvr8WGVcKjXls3ONyZ I0+r1/5EI5FVpjy/QM5ZVhVHPfR8zdovE9Se6TTERtaIEmb4cojK2/jaevTp9pXs "> <TR><TD ALIGN=CENTER HEIGHT=20> </TD></TR> <TR> <TD ALIGN=CENTER> <TABLE style="background-color:#BCD6FF; border:1px solid #6593CE; border-top:0px; margin-top:0px; padding:5px" WIDTH=435 HEIGHT=240 CELLPADDING=0 CELLSPACING=0><TR><TD> <TABLE style="background-color:#FFFFFF; border:1px solid #6593CE; font:normal 11px Geneva,Arial,Helvetica; color:#000000; padding:10px;" WIDTH='100%' HEIGHT='100%' CELLPADDING=0 CELLSPACING=0 BORDER=0><TR><TD> <TABLE WIDTH='100%' HEIGHT='100%' CELLPADDING=0 CELLSPACING=0 BORDER=0> <TR> <TD ALIGN=LEFT WIDTH=48><IMG SRC="https://securemail.earlywarning.com/securereader/Image?c=lock&b=1&rnd=1.50402039862254" HEIGHT=48 WIDTH=48 BORDER=0></TD> <TD colspan=2 ALIGN=CENTER><IMG SRC="https://securemail.earlywarning.com/securereader/Image?c=logo&b=1&rnd=0.475295672511251" BORDER=0> </TD> </TR> <TR><TD colspan=3 HEIGHT=25 style="font: normal 11px Geneva,Arial,Helvetica; border-top:2px solid #6593CE; padding-bottom:5px;"> </TD></TR> <TR><TD colspan=3 ALIGN=CENTER style="font: bold 12px Helvetica; color:#000000;"><input type="submit" name="submitButton" value=" Click to read message "></TD></TR> <TR><TD HEIGHT=20 colspan=3> </TD></TR> <TR><TD ALIGN=CENTER HEIGHT=25 colspan=3> <A HREF="https://securemail.earlywarning.com/securereader/help.jsf?lang=enus" style="font: bold 9px Helvetica; color:#15428B;" target="_blank">More Info</A></TD></TR> <TR><TD COLSPAN=3 ALIGN=LEFT VALIGN=TOP style="font: 9px Helvetica; color:#000000; border-top:2px solid #6593CE; padding-top:5px;"> <b>Disclaimer</b>: This email and its content are confidential and intended solely for the use of the addressee. Please notify the sender if you have received this email in error or simply delete it.</TD></TR> <TR><TD HEIGHT=25 colspan=3> </TD></TR> <TR><TD colspan=3 ALIGN=LEFT style="font: normal 9px Helvetica; color:#1C1C1C;">Secured by Proofpoint Encryption, Copyright © 2009-2012 Proofpoint, Inc. All rights reserved.</TD></TR> </TABLE> </TD></TR></TABLE> </TD></TR></TABLE> </TD> </TR> </form> </TABLE> </BODY> </html> |
From: Olaf H. <ha...@in...> - 2012-03-21 15:00:18
|
Hello, We just published a new revision of the Provenance Vocabulary. With this release the Provenance Vocabulary becomes a domain specific extension of the W3C PROV Ontology (PROV-O) [1]. While PROV-O may be understood as a general purpose ontology for describing and exchanging provenance information for all kinds of things, the Provenance Vocabulary focuses on provenance of Web data. Notice, PROV-O is still under development by the W3C Provenance Working Group [2]. As a consequence of making Provenance Vocabulary a (Web data specific) specialization of PROV-O, all general classes and properties introduced by the vocabulary have been deprecated and shouldn't be used anymore (they will be removed from the Provenance Vocabulary in a later version). For all changes we refer to the Change log [3] in the recent version of the specification document. Cheers, Olaf [1] http://www.w3.org/TR/prov-o/ [2] http://www.w3.org/2011/prov/ [3] http://purl.org/net/provenance/ns.html#sec-changes |
From: Olaf H. <ha...@in...> - 2011-03-14 11:42:24
|
Hey Carsten, Instead of understanding (OSM) change sets as a special kind of creation guidelines, it is also possible to understand change sets as a special kind of data creations. While an osp:Edit creates a new state of a single feature in the OSM dataset, we can understand an osp:Changeset as a prv:DataCreation that creates a new state of the whole OSM dataset. Based on this understanding, osp:Changeset describes provenance on a different level of granularity as osp:Edit does. Alternatively, I would say that it is not really necessary to map each of the terms you introduce to a term in the Provenance Vocabulary. Hence, providing no mapping at all for osp:Changeset is also an option ;-) Greetings, Olaf On Monday 14 March 2011 11:40:05 Carsten Keßler wrote: > The message still waits for approval to get through to the mailing list, so > I am sending this again directly to you guys. > > Cheers, > Carsten > > Forwarded message: > > From: Carsten Keßler <car...@un...> > > To: trd...@li... > > Date: Montag, 14. März 2011 11:37:40 > > Subject: Re: [trdf-prv-vocab-users] Provenance Vocabulary for Open Street > > Map > > > > Hey Jun, hey Olaf, > > > > after reading your discussion, I am also not so sure anymore about > > modeling the Changeset class as subclass of prv:CreationGuideline. > > > > Olaf's explanations about the relationships between FeatureState, Edit, > > and Changeset were absolutely correct. If we make Changeset a subclass > > of prv:CreationGuideline, the question is also, what we gain from this > > stretching of the original idea behind a creation guideline? Does this > > buy us anything? > > > > Then again, I am not sure how to align the Changeset class (which we > > should definitely have, in order to have a complete representation of > > the OSM structure) with the prv ontology. Any ideas where it might fit > > better? > > > > Cheers, > > Carsten > > > > On Freitag, 11. März 2011 at 09:03, Olaf Hartig wrote: > > > Hey Jun, > > > > > > On Thursday 10 March 2011 14:15:54 Jun Zhao wrote: > > > > Hi Olaf and Carsten, > > > > > > > > > That's basically all you need. However, you may also want to model > > > > > your changesets to keep track of which edits belong together. We > > > > > can understand a changeset as a special kind of > > > > > prv:CreationGuideline which describes how to perform a > > > > > prv:DataCreation with which a new state of the complete OSM > > > > > dataset has been created (even if we do not describe this data > > > > > creation explicitly). The only thing that's needed is an > > > > > association of each osp:Changeset with the corresponding osp:Edit > > > > > > > > > instances. Hence, you need a new property: > > > > I don't understand why a changeset is a creation guileline. > > > > > > > > My understanding of Carsten's scenario is that each feature (state) > > > > can be associated with a changeset, which is a collection of edit > > > > events, so that one can figure out what change processes have led to > > > > the existence of this feature (state). > > > > > > Not exactly. First, a changeset (in the context of OSM) is indeed a > > > collection of edit events. But -according to my understanding- it is > > > these edit events that are associated with the states of features (not > > > the changeset). These edit events can be understood as data creations > > > which either created a new, first version/state of a feature or which > > > transformed a specific feature from one version to the next (mostly by > > > adding/removing properties). The changesets collect such edit events > > > (for different ! features) that happened at the same time and that > > > were performed by the same user. > > > > > > > Such a changeset seems like a collection of prv:Executions. And I am > > > > not sure we have any concepts from the Provenance Vocabulary that > > > > can exactly capture this concept. > > > > > > You are right with the first sentence - even more, it is a collection > > > of prv:DataCreations - but -as mentioned before- each of the data > > > creation in such a collection focuses on a different feature (state). > > > > > > Regarding the question whether it would be correct to understand such a > > > collection as a prv:CreationGuideline I am a bit undecided (after > > > reading you concerns). The reason why such an understanding might be > > > problematic is, that a changeset is a collection of executions (of > > > processes) that happened; whereas, in a "pure" creation guideline I > > > would expect descriptions of processes that can be executed. Thus, > > > understanding a changeset as a creation guideline seems -at least- to > > > be stretching the limits. However, may be that's still okay from a > > > pragmatic POV? > > > > > > > And if we take Olaf's suggestion to call each feature at a particular > > > > state as a featurestate (which is absolutely the right thing to do, > > > > IMO:), then each such featurestate can be associated with one and > > > > only one edit execution. I don't see how a featurestate can be > > > > associated with a changeset anymore, which is a collection of edits. > > > > If we enforce this strict distinction between features, how do we > > > > apply changeset to features? Probably I missed something? > > > > > > I guess I already addressed the concerns you raise in that paragraph. > > > However, you're perfectly right, each feature state can only be > > > associated with a single edit event - at least in the role of its data > > > creation (that's why we have the cardinality restriction on > > > prv:createdBy ;) Then each feature state might also be associated with > > > a second edit event by which the feature state was used to create the > > > next state of the corresponding feature (hence, the relationship here > > > is represented by a prv:usedBy property). > > > > > > Cheers, > > > Olaf > > > > > > > cheers, > > > > > > > > Jun > > > > > > > > > osp:includesEdit a owl:ObjectProperty > > > > > > > > > > rdfs:domain osp:Changeset ; > > > > > rdfs:range osp:Edit . > > > > > > > > > > Now, you can describe things like: > > > > > > > > > > <http://osm.org/api/0.6/changeset/3610855> a osp:Changeset ; > > > > > > > > > > osp:includesEdit :edit1 . > > > > > > > > > > Hope that helps, > > > > > Olaf > > > > > > > > > > On Monday 07 March 2011 10:47:25 Carsten Keßler wrote: > > > > > > Hi Olaf, > > > > > > > > > > > > thanks for taking the time to look at our extension. See my > > > > > > answers for your questions below (I'm also CCing this to my > > > > > > coauthors): 1.) You define a class osp:Feature as a sub-class of > > > > > > prv:File and from the > > > > > > > > > > > > > other class that you introduce, I see that a feature can be an > > > > > > > "OSM node with lat/lon coordinates". > > > > > > > > > > > > Either that, or a way or polygon. > > > > > > > > > > > > > I'm not familiar with the OSM terminology. However, > > > > > > > I doubt that it is correct to understand a point in a > > > > > > > coordinate system as a file. > > > > > > > > > > > > Well, it is a bit more than a point in a coordinate system; you > > > > > > can see a more readable serialization of the whole contents by > > > > > > looking at http://www.openstreetmap.org/browse/node/612986688/ > > > > > > as an example > > > > > > > > > > > > > So, what exactly does a URI like > > > > > > > http://osm.org/api/0.6/node/612986688/1 identify? The actual > > > > > > > node? A version of the node? The Web resource with data about > > > > > > > the node? The Web resource with a specific version of data > > > > > > > about that node? > > > > > > > > > > > > I think the last one fits best: it is a web resource with a > > > > > > specific version of data about that node. What you model as a > > > > > > dataitem (the actual node in our case) is not dereferenceable, > > > > > > if I understand it correctly. At least not from the outside, > > > > > > i.e., if you are not running your own OSM server. If you are > > > > > > running the service, you could link it to an entry in your > > > > > > database (?) > > > > > > > > > > > > > 2.) Will an HTTP client always get the same representation when > > > > > > > dereferencing URIs like http://osm.org/api/0.6/node/612986688/1 > > > > > > > ? In other words, does any change create a new version and, > > > > > > > thus, result in another URI, such as > > > > > > > http://osm.org/api/0.6/node/612986688/2 ? > > > > > > > > > > > > Yes, exactly. > > > > > > > > > > > > > 3.) You define a class osp:Changeset as a sub-class of > > > > > > > prv:Artifact; in your example provenance description you have > > > > > > > instances of osp:Changeset as objects in prv:createdBy > > > > > > > triples. This makes these instances a prv:DataCreation as > > > > > > > well. Is that what you intended? > > > > > > > > > > > > Thanks for pointing this out, that's not intended. I'll fix that. > > > > > > > > > > > > > 4.) A few more questions to understand the relationship between > > > > > > > features (osp:Feature), edits (osp:Edit) and changesets > > > > > > > (osp:Changeset): * Is the relationship between edits and > > > > > > > features 1:1, 1:n, or n:1? I.e. does an edit always only > > > > > > > change a single feature? Can a feature be changed by multiple > > > > > > > edits? > > > > > > > > > > > > The Edit class has no corresponding element in OSM. We have > > > > > > introduced it to be able to link a specific change (that was > > > > > > committed with a Changeset) to the affected feature. Every edit > > > > > > can only change one feature, the relationship between edits and > > > > > > features is therefore 1:1. > > > > > > > > > > > > > * Is a changeset some kind of container of edits that have been > > > > > > > performed at the same time by the same user? > > > > > > > > > > > > Yes, exactly. Most of the OSM editors are based on sessions: you > > > > > > open the data for a certain map extent in the editor, make you > > > > > > edits on different features, and finally save everything. This > > > > > > collection is then uploaded to OSM as a Changeset . > > > > > > > > > > > > Best, > > > > > > Carsten > > > > > > > > > > > > > Greetings, > > > > > > > Olaf > > > > > > > > > > > > > > [1] http://dl.dropbox.com/u/9209387/osp-rdf.zip > > > > > > > > --------------------------------------------------------------------- > > > > ------ --- Colocation vs. Managed Hosting > > > > A question and answer guide to determining the best fit > > > > for your organization - today and in the future. > > > > http://p.sf.net/sfu/internap-sfd2d > > > > _______________________________________________ > > > > trdf-prv-vocab-users mailing list > > > > trd...@li... > > > > https://lists.sourceforge.net/lists/listinfo/trdf-prv-vocab-users |
From: Jun Z. <jun...@zo...> - 2011-03-14 11:22:30
|
-------- Original Message -------- Subject: Fw: Provenance Vocabulary for Open Street Map Date: Mon, 14 Mar 2011 10:40:05 +0000 From: Carsten Keßler <car...@un...> To: Olaf Hartig <ha...@in...>, Jun Zhao <jun...@zo...> The message still waits for approval to get through to the mailing list, so I am sending this again directly to you guys. Cheers, Carsten Forwarded message: > From: Carsten Keßler <car...@un...> > To: trd...@li... > Date: Montag, 14. März 2011 11:37:40 > Subject: Re: [trdf-prv-vocab-users] Provenance Vocabulary for Open Street Map > > Hey Jun, hey Olaf, > > after reading your discussion, I am also not so sure anymore about modeling the Changeset class as subclass of prv:CreationGuideline. > > Olaf's explanations about the relationships between FeatureState, Edit, and Changeset were absolutely correct. If we make Changeset a subclass of prv:CreationGuideline, the question is also, what we gain from this stretching of the original idea behind a creation guideline? Does this buy us anything? > > Then again, I am not sure how to align the Changeset class (which we should definitely have, in order to have a complete representation of the OSM structure) with the prv ontology. Any ideas where it might fit better? > > Cheers, > Carsten > On Freitag, 11. März 2011 at 09:03, Olaf Hartig wrote: > > Hey Jun, > > > > On Thursday 10 March 2011 14:15:54 Jun Zhao wrote: > > > Hi Olaf and Carsten, > > > > > > > That's basically all you need. However, you may also want to model your > > > > changesets to keep track of which edits belong together. We can > > > > understand a changeset as a special kind of prv:CreationGuideline which > > > > describes how to perform a prv:DataCreation with which a new state of > > > > the complete OSM dataset has been created (even if we do not describe > > > > this data creation explicitly). The only thing that's needed is an > > > > association of each osp:Changeset with the corresponding osp:Edit > > > > instances. Hence, you need a new property: > > > > > > I don't understand why a changeset is a creation guileline. > > > > > > My understanding of Carsten's scenario is that each feature (state) can > > > be associated with a changeset, which is a collection of edit events, so > > > that one can figure out what change processes have led to the existence > > > of this feature (state). > > > > Not exactly. First, a changeset (in the context of OSM) is indeed a collection > > of edit events. But -according to my understanding- it is these edit events > > that are associated with the states of features (not the changeset). These > > edit events can be understood as data creations which either created a new, > > first version/state of a feature or which transformed a specific feature from > > one version to the next (mostly by adding/removing properties). The changesets > > collect such edit events (for different ! features) that happened at the same > > time and that were performed by the same user. > > > > > Such a changeset seems like a collection of prv:Executions. And I am not > > > sure we have any concepts from the Provenance Vocabulary that can > > > exactly capture this concept. > > > > You are right with the first sentence - even more, it is a collection of > > prv:DataCreations - but -as mentioned before- each of the data creation > > in such a collection focuses on a different feature (state). > > > > Regarding the question whether it would be correct to understand such a > > collection as a prv:CreationGuideline I am a bit undecided (after reading you > > concerns). The reason why such an understanding might be problematic is, > > that a changeset is a collection of executions (of processes) that happened; > > whereas, in a "pure" creation guideline I would expect descriptions of > > processes that can be executed. Thus, understanding a changeset as a creation > > guideline seems -at least- to be stretching the limits. However, may be that's > > still okay from a pragmatic POV? > > > > > And if we take Olaf's suggestion to call each feature at a particular > > > state as a featurestate (which is absolutely the right thing to do, > > > IMO:), then each such featurestate can be associated with one and only > > > one edit execution. I don't see how a featurestate can be associated > > > with a changeset anymore, which is a collection of edits. If we enforce > > > this strict distinction between features, how do we apply changeset to > > > features? Probably I missed something? > > > > I guess I already addressed the concerns you raise in that paragraph. However, > > you're perfectly right, each feature state can only be associated with a > > single edit event - at least in the role of its data creation (that's why we > > have the cardinality restriction on prv:createdBy ;) Then each feature state > > might also be associated with a second edit event by which the feature state > > was used to create the next state of the corresponding feature (hence, the > > relationship here is represented by a prv:usedBy property). > > > > Cheers, > > Olaf > > > > > > > cheers, > > > > > > Jun > > > > > > > osp:includesEdit a owl:ObjectProperty > > > > > > > > rdfs:domain osp:Changeset ; > > > > rdfs:range osp:Edit . > > > > > > > > Now, you can describe things like: > > > > > > > > <http://osm.org/api/0.6/changeset/3610855> a osp:Changeset ; > > > > > > > > osp:includesEdit :edit1 . > > > > > > > > Hope that helps, > > > > Olaf > > > > > > > > On Monday 07 March 2011 10:47:25 Carsten Keßler wrote: > > > > > Hi Olaf, > > > > > > > > > > thanks for taking the time to look at our extension. See my answers for > > > > > your questions below (I'm also CCing this to my coauthors): 1.) You > > > > > define a class osp:Feature as a sub-class of prv:File and from the > > > > > > > > > > > other class that you introduce, I see that a feature can be an "OSM > > > > > > node with lat/lon coordinates". > > > > > > > > > > Either that, or a way or polygon. > > > > > > > > > > > I'm not familiar with the OSM terminology. However, > > > > > > I doubt that it is correct to understand a point in a coordinate system > > > > > > as a file. > > > > > > > > > > Well, it is a bit more than a point in a coordinate system; you can see > > > > > a more readable serialization of the whole contents by looking at > > > > > http://www.openstreetmap.org/browse/node/612986688/ as an example > > > > > > > > > > > So, what exactly does a URI like > > > > > > http://osm.org/api/0.6/node/612986688/1 identify? The actual node? A > > > > > > version of the node? The Web resource with data about the node? The > > > > > > Web resource with a specific version of data about that node? > > > > > > > > > > I think the last one fits best: it is a web resource with a specific > > > > > version of data about that node. What you model as a dataitem (the > > > > > actual node in our case) is not dereferenceable, if I understand it > > > > > correctly. At least not from the outside, i.e., if you are not running > > > > > your own OSM server. If you are running the service, you could link it > > > > > to an entry in your database (?) > > > > > > > > > > > 2.) Will an HTTP client always get the same representation when > > > > > > dereferencing URIs like http://osm.org/api/0.6/node/612986688/1 ? In > > > > > > other words, does any change create a new version and, thus, result in > > > > > > another URI, such as http://osm.org/api/0.6/node/612986688/2 ? > > > > > > > > > > Yes, exactly. > > > > > > > > > > > 3.) You define a class osp:Changeset as a sub-class of prv:Artifact; in > > > > > > your example provenance description you have instances of osp:Changeset > > > > > > as objects in prv:createdBy triples. This makes these instances a > > > > > > prv:DataCreation as well. Is that what you intended? > > > > > > > > > > Thanks for pointing this out, that's not intended. I'll fix that. > > > > > > > > > > > 4.) A few more questions to understand the relationship between > > > > > > features (osp:Feature), edits (osp:Edit) and changesets > > > > > > (osp:Changeset): * Is the relationship between edits and features 1:1, > > > > > > 1:n, or n:1? I.e. does an edit always only change a single feature? > > > > > > Can a feature be changed by multiple edits? > > > > > > > > > > The Edit class has no corresponding element in OSM. We have introduced > > > > > it to be able to link a specific change (that was committed with a > > > > > Changeset) to the affected feature. Every edit can only change one > > > > > feature, the relationship between edits and features is therefore 1:1. > > > > > > > > > > > * Is a changeset some kind of container of edits that have been > > > > > > performed at the same time by the same user? > > > > > > > > > > Yes, exactly. Most of the OSM editors are based on sessions: you open > > > > > the data for a certain map extent in the editor, make you edits on > > > > > different features, and finally save everything. This collection is > > > > > then uploaded to OSM as a Changeset . > > > > > > > > > > Best, > > > > > Carsten > > > > > > > > > > > Greetings, > > > > > > Olaf > > > > > > > > > > > > [1] http://dl.dropbox.com/u/9209387/osp-rdf.zip > > > > > > --------------------------------------------------------------------------- > > > --- Colocation vs. Managed Hosting > > > A question and answer guide to determining the best fit > > > for your organization - today and in the future. > > > http://p.sf.net/sfu/internap-sfd2d > > > _______________________________________________ > > > trdf-prv-vocab-users mailing list > > > trd...@li... > > > https://lists.sourceforge.net/lists/listinfo/trdf-prv-vocab-users > |
From: Jun Z. <jun...@zo...> - 2011-03-11 09:33:18
|
Hi Olaf, All you said makes sense to me. I don't see any obvious benefits for them to define changeset as a prv:CreationGuideline nor it violates anything if they do do so. I am going to meet Tim next week in Oxford, who is also working on this with Carsten. Hopefully we will have enough time to go into details on this and report back to the list. cheers, Jun On 11/03/11 08:03, Olaf Hartig wrote: > Hey Jun, > > On Thursday 10 March 2011 14:15:54 Jun Zhao wrote: >> Hi Olaf and Carsten, >> >>> That's basically all you need. However, you may also want to model your >>> changesets to keep track of which edits belong together. We can >>> understand a changeset as a special kind of prv:CreationGuideline which >>> describes how to perform a prv:DataCreation with which a new state of >>> the complete OSM dataset has been created (even if we do not describe >>> this data creation explicitly). The only thing that's needed is an >>> association of each osp:Changeset with the corresponding osp:Edit >>> instances. Hence, you need a new property: >> >> I don't understand why a changeset is a creation guileline. >> >> My understanding of Carsten's scenario is that each feature (state) can >> be associated with a changeset, which is a collection of edit events, so >> that one can figure out what change processes have led to the existence >> of this feature (state). > > Not exactly. First, a changeset (in the context of OSM) is indeed a collection > of edit events. But -according to my understanding- it is these edit events > that are associated with the states of features (not the changeset). These > edit events can be understood as data creations which either created a new, > first version/state of a feature or which transformed a specific feature from > one version to the next (mostly by adding/removing properties). The changesets > collect such edit events (for different ! features) that happened at the same > time and that were performed by the same user. > >> Such a changeset seems like a collection of prv:Executions. And I am not >> sure we have any concepts from the Provenance Vocabulary that can >> exactly capture this concept. > > You are right with the first sentence - even more, it is a collection of > prv:DataCreations - but -as mentioned before- each of the data creation > in such a collection focuses on a different feature (state). > > Regarding the question whether it would be correct to understand such a > collection as a prv:CreationGuideline I am a bit undecided (after reading you > concerns). The reason why such an understanding might be problematic is, > that a changeset is a collection of executions (of processes) that happened; > whereas, in a "pure" creation guideline I would expect descriptions of > processes that can be executed. Thus, understanding a changeset as a creation > guideline seems -at least- to be stretching the limits. However, may be that's > still okay from a pragmatic POV? > >> And if we take Olaf's suggestion to call each feature at a particular >> state as a featurestate (which is absolutely the right thing to do, >> IMO:), then each such featurestate can be associated with one and only >> one edit execution. I don't see how a featurestate can be associated >> with a changeset anymore, which is a collection of edits. If we enforce >> this strict distinction between features, how do we apply changeset to >> features? Probably I missed something? > > I guess I already addressed the concerns you raise in that paragraph. However, > you're perfectly right, each feature state can only be associated with a > single edit event - at least in the role of its data creation (that's why we > have the cardinality restriction on prv:createdBy ;) Then each feature state > might also be associated with a second edit event by which the feature state > was used to create the next state of the corresponding feature (hence, the > relationship here is represented by a prv:usedBy property). > > Cheers, > Olaf > > >> cheers, >> >> Jun >> >>> osp:includesEdit a owl:ObjectProperty >>> >>> rdfs:domain osp:Changeset ; >>> rdfs:range osp:Edit . >>> >>> Now, you can describe things like: >>> >>> <http://osm.org/api/0.6/changeset/3610855> a osp:Changeset ; >>> >>> osp:includesEdit :edit1 . >>> >>> Hope that helps, >>> Olaf >>> >>> On Monday 07 March 2011 10:47:25 Carsten Keßler wrote: >>>> Hi Olaf, >>>> >>>> thanks for taking the time to look at our extension. See my answers for >>>> your questions below (I'm also CCing this to my coauthors): 1.) You >>>> define a class osp:Feature as a sub-class of prv:File and from the >>>> >>>>> other class that you introduce, I see that a feature can be an "OSM >>>>> node with lat/lon coordinates". >>>> >>>> Either that, or a way or polygon. >>>> >>>>> I'm not familiar with the OSM terminology. However, >>>>> I doubt that it is correct to understand a point in a coordinate system >>>>> as a file. >>>> >>>> Well, it is a bit more than a point in a coordinate system; you can see >>>> a more readable serialization of the whole contents by looking at >>>> http://www.openstreetmap.org/browse/node/612986688/ as an example >>>> >>>>> So, what exactly does a URI like >>>>> http://osm.org/api/0.6/node/612986688/1 identify? The actual node? A >>>>> version of the node? The Web resource with data about the node? The >>>>> Web resource with a specific version of data about that node? >>>> >>>> I think the last one fits best: it is a web resource with a specific >>>> version of data about that node. What you model as a dataitem (the >>>> actual node in our case) is not dereferenceable, if I understand it >>>> correctly. At least not from the outside, i.e., if you are not running >>>> your own OSM server. If you are running the service, you could link it >>>> to an entry in your database (?) >>>> >>>>> 2.) Will an HTTP client always get the same representation when >>>>> dereferencing URIs like http://osm.org/api/0.6/node/612986688/1 ? In >>>>> other words, does any change create a new version and, thus, result in >>>>> another URI, such as http://osm.org/api/0.6/node/612986688/2 ? >>>> >>>> Yes, exactly. >>>> >>>>> 3.) You define a class osp:Changeset as a sub-class of prv:Artifact; in >>>>> your example provenance description you have instances of osp:Changeset >>>>> as objects in prv:createdBy triples. This makes these instances a >>>>> prv:DataCreation as well. Is that what you intended? >>>> >>>> Thanks for pointing this out, that's not intended. I'll fix that. >>>> >>>>> 4.) A few more questions to understand the relationship between >>>>> features (osp:Feature), edits (osp:Edit) and changesets >>>>> (osp:Changeset): * Is the relationship between edits and features 1:1, >>>>> 1:n, or n:1? I.e. does an edit always only change a single feature? >>>>> Can a feature be changed by multiple edits? >>>> >>>> The Edit class has no corresponding element in OSM. We have introduced >>>> it to be able to link a specific change (that was committed with a >>>> Changeset) to the affected feature. Every edit can only change one >>>> feature, the relationship between edits and features is therefore 1:1. >>>> >>>>> * Is a changeset some kind of container of edits that have been >>>>> performed at the same time by the same user? >>>> >>>> Yes, exactly. Most of the OSM editors are based on sessions: you open >>>> the data for a certain map extent in the editor, make you edits on >>>> different features, and finally save everything. This collection is >>>> then uploaded to OSM as a Changeset . >>>> >>>> Best, >>>> Carsten >>>> >>>>> Greetings, >>>>> Olaf >>>>> >>>>> [1] http://dl.dropbox.com/u/9209387/osp-rdf.zip >> >> --------------------------------------------------------------------------- >> --- Colocation vs. Managed Hosting >> A question and answer guide to determining the best fit >> for your organization - today and in the future. >> http://p.sf.net/sfu/internap-sfd2d >> _______________________________________________ >> trdf-prv-vocab-users mailing list >> trd...@li... >> https://lists.sourceforge.net/lists/listinfo/trdf-prv-vocab-users |
From: Olaf H. <ha...@in...> - 2011-03-11 08:03:18
|
Hey Jun, On Thursday 10 March 2011 14:15:54 Jun Zhao wrote: > Hi Olaf and Carsten, > > > That's basically all you need. However, you may also want to model your > > changesets to keep track of which edits belong together. We can > > understand a changeset as a special kind of prv:CreationGuideline which > > describes how to perform a prv:DataCreation with which a new state of > > the complete OSM dataset has been created (even if we do not describe > > this data creation explicitly). The only thing that's needed is an > > association of each osp:Changeset with the corresponding osp:Edit > > instances. Hence, you need a new property: > > I don't understand why a changeset is a creation guileline. > > My understanding of Carsten's scenario is that each feature (state) can > be associated with a changeset, which is a collection of edit events, so > that one can figure out what change processes have led to the existence > of this feature (state). Not exactly. First, a changeset (in the context of OSM) is indeed a collection of edit events. But -according to my understanding- it is these edit events that are associated with the states of features (not the changeset). These edit events can be understood as data creations which either created a new, first version/state of a feature or which transformed a specific feature from one version to the next (mostly by adding/removing properties). The changesets collect such edit events (for different ! features) that happened at the same time and that were performed by the same user. > Such a changeset seems like a collection of prv:Executions. And I am not > sure we have any concepts from the Provenance Vocabulary that can > exactly capture this concept. You are right with the first sentence - even more, it is a collection of prv:DataCreations - but -as mentioned before- each of the data creation in such a collection focuses on a different feature (state). Regarding the question whether it would be correct to understand such a collection as a prv:CreationGuideline I am a bit undecided (after reading you concerns). The reason why such an understanding might be problematic is, that a changeset is a collection of executions (of processes) that happened; whereas, in a "pure" creation guideline I would expect descriptions of processes that can be executed. Thus, understanding a changeset as a creation guideline seems -at least- to be stretching the limits. However, may be that's still okay from a pragmatic POV? > And if we take Olaf's suggestion to call each feature at a particular > state as a featurestate (which is absolutely the right thing to do, > IMO:), then each such featurestate can be associated with one and only > one edit execution. I don't see how a featurestate can be associated > with a changeset anymore, which is a collection of edits. If we enforce > this strict distinction between features, how do we apply changeset to > features? Probably I missed something? I guess I already addressed the concerns you raise in that paragraph. However, you're perfectly right, each feature state can only be associated with a single edit event - at least in the role of its data creation (that's why we have the cardinality restriction on prv:createdBy ;) Then each feature state might also be associated with a second edit event by which the feature state was used to create the next state of the corresponding feature (hence, the relationship here is represented by a prv:usedBy property). Cheers, Olaf > cheers, > > Jun > > > osp:includesEdit a owl:ObjectProperty > > > > rdfs:domain osp:Changeset ; > > rdfs:range osp:Edit . > > > > Now, you can describe things like: > > > > <http://osm.org/api/0.6/changeset/3610855> a osp:Changeset ; > > > > osp:includesEdit :edit1 . > > > > Hope that helps, > > Olaf > > > > On Monday 07 March 2011 10:47:25 Carsten Keßler wrote: > >> Hi Olaf, > >> > >> thanks for taking the time to look at our extension. See my answers for > >> your questions below (I'm also CCing this to my coauthors): 1.) You > >> define a class osp:Feature as a sub-class of prv:File and from the > >> > >>> other class that you introduce, I see that a feature can be an "OSM > >>> node with lat/lon coordinates". > >> > >> Either that, or a way or polygon. > >> > >>> I'm not familiar with the OSM terminology. However, > >>> I doubt that it is correct to understand a point in a coordinate system > >>> as a file. > >> > >> Well, it is a bit more than a point in a coordinate system; you can see > >> a more readable serialization of the whole contents by looking at > >> http://www.openstreetmap.org/browse/node/612986688/ as an example > >> > >>> So, what exactly does a URI like > >>> http://osm.org/api/0.6/node/612986688/1 identify? The actual node? A > >>> version of the node? The Web resource with data about the node? The > >>> Web resource with a specific version of data about that node? > >> > >> I think the last one fits best: it is a web resource with a specific > >> version of data about that node. What you model as a dataitem (the > >> actual node in our case) is not dereferenceable, if I understand it > >> correctly. At least not from the outside, i.e., if you are not running > >> your own OSM server. If you are running the service, you could link it > >> to an entry in your database (?) > >> > >>> 2.) Will an HTTP client always get the same representation when > >>> dereferencing URIs like http://osm.org/api/0.6/node/612986688/1 ? In > >>> other words, does any change create a new version and, thus, result in > >>> another URI, such as http://osm.org/api/0.6/node/612986688/2 ? > >> > >> Yes, exactly. > >> > >>> 3.) You define a class osp:Changeset as a sub-class of prv:Artifact; in > >>> your example provenance description you have instances of osp:Changeset > >>> as objects in prv:createdBy triples. This makes these instances a > >>> prv:DataCreation as well. Is that what you intended? > >> > >> Thanks for pointing this out, that's not intended. I'll fix that. > >> > >>> 4.) A few more questions to understand the relationship between > >>> features (osp:Feature), edits (osp:Edit) and changesets > >>> (osp:Changeset): * Is the relationship between edits and features 1:1, > >>> 1:n, or n:1? I.e. does an edit always only change a single feature? > >>> Can a feature be changed by multiple edits? > >> > >> The Edit class has no corresponding element in OSM. We have introduced > >> it to be able to link a specific change (that was committed with a > >> Changeset) to the affected feature. Every edit can only change one > >> feature, the relationship between edits and features is therefore 1:1. > >> > >>> * Is a changeset some kind of container of edits that have been > >>> performed at the same time by the same user? > >> > >> Yes, exactly. Most of the OSM editors are based on sessions: you open > >> the data for a certain map extent in the editor, make you edits on > >> different features, and finally save everything. This collection is > >> then uploaded to OSM as a Changeset . > >> > >> Best, > >> Carsten > >> > >>> Greetings, > >>> Olaf > >>> > >>> [1] http://dl.dropbox.com/u/9209387/osp-rdf.zip > > --------------------------------------------------------------------------- > --- Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > trdf-prv-vocab-users mailing list > trd...@li... > https://lists.sourceforge.net/lists/listinfo/trdf-prv-vocab-users |
From: Jun Z. <jun...@zo...> - 2011-03-10 14:15:43
|
Hi Olaf and Carsten, > That's basically all you need. However, you may also want to model your > changesets to keep track of which edits belong together. We can understand a > changeset as a special kind of prv:CreationGuideline which describes how to > perform a prv:DataCreation with which a new state of the complete OSM dataset > has been created (even if we do not describe this data creation explicitly). > The only thing that's needed is an association of each osp:Changeset with the > corresponding osp:Edit instances. Hence, you need a new property: I don't understand why a changeset is a creation guileline. My understanding of Carsten's scenario is that each feature (state) can be associated with a changeset, which is a collection of edit events, so that one can figure out what change processes have led to the existence of this feature (state). Such a changeset seems like a collection of prv:Executions. And I am not sure we have any concepts from the Provenance Vocabulary that can exactly capture this concept. And if we take Olaf's suggestion to call each feature at a particular state as a featurestate (which is absolutely the right thing to do, IMO:), then each such featurestate can be associated with one and only one edit execution. I don't see how a featurestate can be associated with a changeset anymore, which is a collection of edits. If we enforce this strict distinction between features, how do we apply changeset to features? Probably I missed something? cheers, Jun > > osp:includesEdit a owl:ObjectProperty > rdfs:domain osp:Changeset ; > rdfs:range osp:Edit . > > Now, you can describe things like: > > <http://osm.org/api/0.6/changeset/3610855> a osp:Changeset ; > osp:includesEdit :edit1 . > > Hope that helps, > Olaf > > > On Monday 07 March 2011 10:47:25 Carsten Keßler wrote: >> Hi Olaf, >> >> thanks for taking the time to look at our extension. See my answers for >> your questions below (I'm also CCing this to my coauthors): 1.) You define >> a class osp:Feature as a sub-class of prv:File and from the >> >>> other class that you introduce, I see that a feature can be an "OSM node >>> with lat/lon coordinates". >> >> Either that, or a way or polygon. >> >>> I'm not familiar with the OSM terminology. However, >>> I doubt that it is correct to understand a point in a coordinate system >>> as a file. >> >> Well, it is a bit more than a point in a coordinate system; you can see a >> more readable serialization of the whole contents by looking at >> http://www.openstreetmap.org/browse/node/612986688/ as an example >> >>> So, what exactly does a URI like http://osm.org/api/0.6/node/612986688/1 >>> identify? The actual node? A version of the node? The Web resource with >>> data about the node? The Web resource with a specific version of data >>> about that node? >> >> I think the last one fits best: it is a web resource with a specific >> version of data about that node. What you model as a dataitem (the actual >> node in our case) is not dereferenceable, if I understand it correctly. At >> least not from the outside, i.e., if you are not running your own OSM >> server. If you are running the service, you could link it to an entry in >> your database (?) >> >>> 2.) Will an HTTP client always get the same representation when >>> dereferencing URIs like http://osm.org/api/0.6/node/612986688/1 ? In >>> other words, does any change create a new version and, thus, result in >>> another URI, such as http://osm.org/api/0.6/node/612986688/2 ? >> >> Yes, exactly. >> >>> 3.) You define a class osp:Changeset as a sub-class of prv:Artifact; in >>> your example provenance description you have instances of osp:Changeset >>> as objects in prv:createdBy triples. This makes these instances a >>> prv:DataCreation as well. Is that what you intended? >> >> Thanks for pointing this out, that's not intended. I'll fix that. >> >>> 4.) A few more questions to understand the relationship between features >>> (osp:Feature), edits (osp:Edit) and changesets (osp:Changeset): >>> * Is the relationship between edits and features 1:1, 1:n, or n:1? I.e. >>> does an edit always only change a single feature? Can a feature be >>> changed by multiple edits? >> >> The Edit class has no corresponding element in OSM. We have introduced it >> to be able to link a specific change (that was committed with a Changeset) >> to the affected feature. Every edit can only change one feature, the >> relationship between edits and features is therefore 1:1. >> >>> * Is a changeset some kind of container of edits that have been performed >>> at the same time by the same user? >> >> Yes, exactly. Most of the OSM editors are based on sessions: you open the >> data for a certain map extent in the editor, make you edits on different >> features, and finally save everything. This collection is then uploaded to >> OSM as a Changeset . >> >> Best, >> Carsten >> >>> Greetings, >>> Olaf >>> >>> [1] http://dl.dropbox.com/u/9209387/osp-rdf.zip |
From: Jun Z. <jun...@zo...> - 2011-03-09 11:48:03
|
>> >> We're happy enough to put this class into a namespace of our own, but if >> you think it makes sense to have this in prvTypes, or need any additional >> information on it, just let us know. > > We did not yet decide on a strategy what exactly we want to have in our types > module. It boils down to the question whether we want to add anything that > could be relevant from any (Linked Data publishing) tool or if we focus on the > most important tools (but how to decide on what is important enough) or if we > still keep this generic and propose additional, more tool-specific type > modules. However, as long as we don't have a decision on this question, I > propose i) you use a name from your namespace for that class and ii) for each > instance of that class you provide an additional rdf:type triple with the most > specific class from our Provenance Vocabulary. Yes, I agree with Olaf on this. And it would also be nice if you could send us a link to the extended module you defined :) cheers, Jun > > Greetings, > Olaf > > ------------------------------------------------------------------------------ > What You Don't Know About Data Connectivity CAN Hurt You > This paper provides an overview of data connectivity, details > its effect on application quality, and explores various alternative > solutions. http://p.sf.net/sfu/progress-d2d > _______________________________________________ > trdf-prv-vocab-users mailing list > trd...@li... > https://lists.sourceforge.net/lists/listinfo/trdf-prv-vocab-users |
From: Jun Z. <jun...@zo...> - 2011-03-08 10:09:46
|
Hi Nur, Are you interested in describing provenance information related to how :dbpedia, :linkedgeodata, and :dbpedia2linkedgeodata were generated, e.g. using which tool, by whom, which organization etc? I think the latest VoID (http://www.w3.org/TR/void/) also shows how to provide some general provenance-related metaddata using DC. Which one do you desire? cheers, Jun On 23/02/11 16:14, Nur Aini Rakhmawati Gunawan wrote: > Dear all, > > let me introduce my self. I am Nur Aini Rakhmawati who are working on > LATC project http://latc-project.eu. I have responsibility to produce > linkset from two datasets by using SILK framework[1]. This following > N-triples of One of void file that already generated > > @prefix rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#> . > @prefix rdfs:<http://www.w3.org/2000/01/rdf-schema#> . > @prefix owl:<http://www.w3.org/2002/07/owl#> . > @prefix void:<http://rdfs.org/ns/void#> . > @prefix :<#> . > :dbpedia a void:Dataset; > void:sparqlEndpoint<http://live.dbpedia.org/sparql/>; > . > :linkedgeodata a void:Dataset; > void:sparqlEndpoint<http://linkedgeodata.org/sparql/>; > . > :dbpedia2linkedgeodata a void:Linkset ; > void:linkPredicate owl:sameAs; > void:target :dbpedia; > void:target :linkedgeodata ; > void:triples 0; > . > > Could you give me example to add provenance of above triples ? > for furthermore information, you could visit this link[2] > > > thanks, > > > regards, > > > Nur Aini Rakhmawati > > > > [1] http://www4.wiwiss.fu-berlin.de/bizer/silk/ > [2] http://demo.sindice.net/latctemp/2011-02-21/dbpedia-lgd_lake.xml/ > > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search& Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT data > generated by your applications, servers and devices whether physical, virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > trdf-prv-vocab-users mailing list > trd...@li... > https://lists.sourceforge.net/lists/listinfo/trdf-prv-vocab-users |
From: Olaf H. <ha...@in...> - 2011-03-07 19:33:01
|
Hey Richard, On Monday 07 March 2011 18:50:25 Richard Cyganiak wrote: > [...] > > 2.) You write that the console manages the execution but according to the > > provenance description the only involvement of :console seems to be > > that it provided the :linkspec In contrast, :SilkMapReduce seems to be > > the actual component which managed (i.e. performed) the execution. > > So, here's what's going on. > > Users write a link spec. > > They add the link spec to the Console. > > There is an automated component called the Runtime which continuously > monitors the Console for new and updated link specs, and schedules them > for execution if computing resources are available. > > What's executed is a software component called Silk MapReduce. This > component actually computes the links. > > I'm not sure though if we really need to express all of this with that > level of detail. What we really want to capture is the information that > someone would need to reproduce our result. What data was used, what link > spec was used, what version of Silk MapReduce. Who created the link spec. > So the Console and Runtime don't really matter all that much in this > picture. I agree absolutely. It was just that I couldn't map the terminology used in your brief explanation to the names you used in the sample data. > [...] > > 5.) You define prvTypes:SilkLinkSpecification in the namespace of our > > types module. Do you think it should go there or do you plan to provide > > your own definition document? > > We're happy enough to put this class into a namespace of our own, but if > you think it makes sense to have this in prvTypes, or need any additional > information on it, just let us know. We did not yet decide on a strategy what exactly we want to have in our types module. It boils down to the question whether we want to add anything that could be relevant from any (Linked Data publishing) tool or if we focus on the most important tools (but how to decide on what is important enough) or if we still keep this generic and propose additional, more tool-specific type modules. However, as long as we don't have a decision on this question, I propose i) you use a name from your namespace for that class and ii) for each instance of that class you provide an additional rdf:type triple with the most specific class from our Provenance Vocabulary. Greetings, Olaf |
From: Olaf H. <ha...@in...> - 2011-03-07 12:54:33
|
Hey Carsten, (sorry, for the previous mail - I accidentally hit the Send button too early) Thanks for clarification. Now, my interpretation of the things that you want to model (and their relationship to our Provenance Vocabulary) is as follows: Conceptually, I would understand each OSM node as data about a specific geo point. By "data" I mean the very abstract thing that can change over time. Furthermore, I would understand the thing identified by http://osm.org/api/0.6/node/612986688/1 as a specific representation (or state, if you will) of such "data", i.e. as a prv:DataItem. A prv:DataItem can indeed be a Web resource again, i.e. something of which a Web representation can be delivered via HTTP. Such a Web representation (of a Web resource that is a data item) is the XML document (a prv:File) that I retrieve when I dereference the URI http://osm.org/api/0.6/node/612986688/1. Now, I propose to rename your class osp:Feature to osp:FeatureState, osp:FeatureDescription, osp:FeatureRepresentation, or osp:FeatureVersion (similarly for osp:Node and osp:Way) and make it a sub-class of prv:DataItem. Furthermore, an osp:Edit is a sub-class of prv:DataCreation and it is the rdfs:domain of the properties that you introduce (e.g. osp:addsTag). In the provenance descriptions you should refer to the previous version of a feature that was changed by an osp:Edit using the property prv:usedData. Here's an example: <http://osm.org/api/0.6/node/612986688/1> a osp:NodeState ; prv:createdBy :edit1 . :edit1 a osp:Edit ; prv:performedBy <http://osm.org/user/1248> ; prv:performedAt "Wed, 13 Jan 2010 15:42:08 +0000" ; osp:addsTag "amenity = cafe" ; osp:addsTag "name = fyal" ; osp:changesGeometry "New node" . <http://osm.org/api/0.6/node/612986688/2> a osp:NodeState ; prv:createdBy :edit2 ; prv:precededBy <http://osm.org/api/0.6/node/612986688/1> . :edit2 a osp:Edit ; prv:performedBy <http://osm.org/user/1248> ; prv:performedAt "Fri, 29 Jan 2010 22:05:49 +0000" ; osp:addsTag "website = http://www.fyalcentral.de/" ; prv:usedData <http://osm.org/api/0.6/node/612986688/1> . That's basically all you need. However, you may also want to model your changesets to keep track of which edits belong together. We can understand a changeset as a special kind of prv:CreationGuideline which describes how to perform a prv:DataCreation with which a new state of the complete OSM dataset has been created (even if we do not describe this data creation explicitly). The only thing that's needed is an association of each osp:Changeset with the corresponding osp:Edit instances. Hence, you need a new property: osp:includesEdit a owl:ObjectProperty rdfs:domain osp:Changeset ; rdfs:range osp:Edit . Now, you can describe things like: <http://osm.org/api/0.6/changeset/3610855> a osp:Changeset ; osp:includesEdit :edit1 . Hope that helps, Olaf On Monday 07 March 2011 10:47:25 Carsten Keßler wrote: > Hi Olaf, > > thanks for taking the time to look at our extension. See my answers for > your questions below (I'm also CCing this to my coauthors): 1.) You define > a class osp:Feature as a sub-class of prv:File and from the > > > other class that you introduce, I see that a feature can be an "OSM node > > with lat/lon coordinates". > > Either that, or a way or polygon. > > > I'm not familiar with the OSM terminology. However, > > I doubt that it is correct to understand a point in a coordinate system > > as a file. > > Well, it is a bit more than a point in a coordinate system; you can see a > more readable serialization of the whole contents by looking at > http://www.openstreetmap.org/browse/node/612986688/ as an example > > > So, what exactly does a URI like http://osm.org/api/0.6/node/612986688/1 > > identify? The actual node? A version of the node? The Web resource with > > data about the node? The Web resource with a specific version of data > > about that node? > > I think the last one fits best: it is a web resource with a specific > version of data about that node. What you model as a dataitem (the actual > node in our case) is not dereferenceable, if I understand it correctly. At > least not from the outside, i.e., if you are not running your own OSM > server. If you are running the service, you could link it to an entry in > your database (?) > > > 2.) Will an HTTP client always get the same representation when > > dereferencing URIs like http://osm.org/api/0.6/node/612986688/1 ? In > > other words, does any change create a new version and, thus, result in > > another URI, such as http://osm.org/api/0.6/node/612986688/2 ? > > Yes, exactly. > > > 3.) You define a class osp:Changeset as a sub-class of prv:Artifact; in > > your example provenance description you have instances of osp:Changeset > > as objects in prv:createdBy triples. This makes these instances a > > prv:DataCreation as well. Is that what you intended? > > Thanks for pointing this out, that's not intended. I'll fix that. > > > 4.) A few more questions to understand the relationship between features > > (osp:Feature), edits (osp:Edit) and changesets (osp:Changeset): > > * Is the relationship between edits and features 1:1, 1:n, or n:1? I.e. > > does an edit always only change a single feature? Can a feature be > > changed by multiple edits? > > The Edit class has no corresponding element in OSM. We have introduced it > to be able to link a specific change (that was committed with a Changeset) > to the affected feature. Every edit can only change one feature, the > relationship between edits and features is therefore 1:1. > > > * Is a changeset some kind of container of edits that have been performed > > at the same time by the same user? > > Yes, exactly. Most of the OSM editors are based on sessions: you open the > data for a certain map extent in the editor, make you edits on different > features, and finally save everything. This collection is then uploaded to > OSM as a Changeset . > > Best, > Carsten > > > Greetings, > > Olaf > > > > [1] http://dl.dropbox.com/u/9209387/osp-rdf.zip |
From: Olaf H. <ha...@in...> - 2011-03-07 12:06:57
|
Hey Carsten, Thanks for clarification. Now, my interpretation of the things that you want to model (and their relationship to our Provenance Vocabulary) is as follows: On Monday 07 March 2011 10:47:25 Carsten Keßler wrote: > Hi Olaf, > > thanks for taking the time to look at our extension. See my answers for > your questions below (I'm also CCing this to my coauthors): 1.) You define > a class osp:Feature as a sub-class of prv:File and from the > > > other class that you introduce, I see that a feature can be an "OSM node > > with lat/lon coordinates". > > Either that, or a way or polygon. > > > I'm not familiar with the OSM terminology. However, > > I doubt that it is correct to understand a point in a coordinate system > > as a file. > > Well, it is a bit more than a point in a coordinate system; you can see a > more readable serialization of the whole contents by looking at > http://www.openstreetmap.org/browse/node/612986688/ as an example > > > So, what exactly does a URI like http://osm.org/api/0.6/node/612986688/1 > > identify? The actual node? A version of the node? The Web resource with > > data about the node? The Web resource with a specific version of data > > about that node? > > I think the last one fits best: it is a web resource with a specific > version of data about that node. What you model as a dataitem (the actual > node in our case) Not exactly. When we understand an OSM node as "data" about a geo point then the thing identified by http://osm.org/api/0.6/node/612986688/1 can be understood as a specific representation (or state, if you will) of this "data", i.e. as a prv:DataItem. > is not dereferenceable, if I understand it correctly. At > least not from the outside, i.e., if you are not running your own OSM > server. If you are running the service, you could link it to an entry in > your database (?) > > > 2.) Will an HTTP client always get the same representation when > > dereferencing URIs like http://osm.org/api/0.6/node/612986688/1 ? In > > other words, does any change create a new version and, thus, result in > > another URI, such as http://osm.org/api/0.6/node/612986688/2 ? > > Yes, exactly. Well, in that case I would understand the thing identified by URI http://osm.org/api/0.6/node/612986688/1 as a prv:DataItem. It is a representation of data about a geo point. > > 3.) You define a class osp:Changeset as a sub-class of prv:Artifact; in > > your example provenance description you have instances of osp:Changeset > > as objects in prv:createdBy triples. This makes these instances a > > prv:DataCreation as well. Is that what you intended? > > Thanks for pointing this out, that's not intended. I'll fix that. > > > 4.) A few more questions to understand the relationship between features > > (osp:Feature), edits (osp:Edit) and changesets (osp:Changeset): > > * Is the relationship between edits and features 1:1, 1:n, or n:1? I.e. > > does an edit always only change a single feature? Can a feature be > > changed by multiple edits? > > The Edit class has no corresponding element in OSM. We have introduced it > to be able to link a specific change (that was committed with a Changeset) > to the affected feature. Every edit can only change one feature, the > relationship between edits and features is therefore 1:1. > > > * Is a changeset some kind of container of edits that have been performed > > at the same time by the same user? > > Yes, exactly. Most of the OSM editors are based on sessions: you open the > data for a certain map extent in the editor, make you edits on different > features, and finally save everything. This collection is then uploaded to > OSM as a Changeset . > > Best, > Carsten > > > Greetings, > > Olaf > > > > [1] http://dl.dropbox.com/u/9209387/osp-rdf.zip |
From: Olaf H. <ha...@in...> - 2011-03-07 10:20:36
|
Hello Carsten, (CCing the Provenance Vocabulary mailing list) Thanks for pointing me to your Open Street Map extension [1] for our Provenance Vocabulary. In order to comment appropriately on your extension, let me ask a few questions first: 1.) You define a class osp:Feature as a sub-class of prv:File and from the other class that you introduce, I see that a feature can be an "OSM node with lat/lon coordinates". I'm not familiar with the OSM terminology. However, I doubt that it is correct to understand a point in a coordinate system as a file. So, what exactly does a URI like http://osm.org/api/0.6/node/612986688/1 identify? The actual node? A version of the node? The Web resource with data about the node? The Web resource with a specific version of data about that node? 2.) Will an HTTP client always get the same representation when dereferencing URIs like http://osm.org/api/0.6/node/612986688/1 ? In other words, does any change create a new version and, thus, result in another URI, such as http://osm.org/api/0.6/node/612986688/2 ? 3.) You define a class osp:Changeset as a sub-class of prv:Artifact; in your example provenance description you have instances of osp:Changeset as objects in prv:createdBy triples. This makes these instances a prv:DataCreation as well. Is that what you intended? 4.) A few more questions to understand the relationship between features (osp:Feature), edits (osp:Edit) and changesets (osp:Changeset): * Is the relationship between edits and features 1:1, 1:n, or n:1? I.e. does an edit always only change a single feature? Can a feature be changed by multiple edits? * Is a changeset some kind of container of edits that have been performed at the same time by the same user? Greetings, Olaf [1] http://dl.dropbox.com/u/9209387/osp-rdf.zip |
From: Olaf H. <ha...@in...> - 2011-03-07 09:30:11
|
Hey Richard, Overall, the modeling looks good. A few comments and suggestions: 1.) You may want to add prv:usedData :dbpedia ; prv:usedData :linkedgeodata ; to the prv:DataCreation of :dbpedia2linkedgeodata 2.) You write that the console manages the execution but according to the provenance description the only involvement of :console seems to be that it provided the :linkspec In contrast, :SilkMapReduce seems to be the actual component which managed (i.e. performed) the execution. 3.) (Probably related to 2.) according to the description, :SilkMapReduce only performed the prv:DataAccess of :linkspec but it is described to be a prvTypes:DataCreatingService. Hence, I guess you forgot to state that the prv:DataCreation of :dbpedia2linkedgeodata was also prv:performedBy :SilkMapReduce ? 4.) :linkspec is described to be a prvTypes:silkmapreduce but this type does neither exist in our types module nor is it defined in the provenance description itself. Instead, you define prvTypes:SilkLinkSpecification, which, I think, is what you wanted to use as type for :linkspec. 5.) You define prvTypes:SilkLinkSpecification in the namespace of our types module. Do you think it should go there or do you plan to provide your own definition document? Greetings, Olaf On Saturday 05 March 2011 15:58:24 Richard Cyganiak wrote: > Dear all, > > We're exploring the use of the Provenance Vocabulary in the LATC project. > In LATC, an interlinking engine (Silk) uses a link specification (written > by an author) to create a linkset (set of RDF triples) between two RDF > datasets. The execution is managed by an automated component called the > LATC Runtime/Console. > > Here's our attempt at modeling this using the Provenance Vocabulary: > > http://demo.sindice.net/latctemp/mountain.ttl > > The void:Linkset is the generated artifact. > > Any comments would be highly welcome! > > Thanks a lot, > Richard |
From: Nur A. R. G. <nur...@de...> - 2011-02-23 16:15:23
|
Dear all, let me introduce my self. I am Nur Aini Rakhmawati who are working on LATC project http://latc-project.eu. I have responsibility to produce linkset from two datasets by using SILK framework[1]. This following N-triples of One of void file that already generated @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix void: <http://rdfs.org/ns/void#> . @prefix : <#> . :dbpedia a void:Dataset; void:sparqlEndpoint <http://live.dbpedia.org/sparql/>; . :linkedgeodata a void:Dataset; void:sparqlEndpoint <http://linkedgeodata.org/sparql/>; . :dbpedia2linkedgeodata a void:Linkset ; void:linkPredicate owl:sameAs; void:target :dbpedia; void:target :linkedgeodata ; void:triples 0; . Could you give me example to add provenance of above triples ? for furthermore information, you could visit this link[2] thanks, regards, Nur Aini Rakhmawati [1] http://www4.wiwiss.fu-berlin.de/bizer/silk/ [2] http://demo.sindice.net/latctemp/2011-02-21/dbpedia-lgd_lake.xml/ |
From: Olaf H. <ha...@in...> - 2010-07-25 22:31:18
|
Hello, The new revision 0.5 of the Provenance Vocabulary is available [1]. This new release includes several changes as described in the changelog [2]. Since this revision we also provide an overview diagram [3] that illustrates all classes and properties defined in the Provenance Vocabulary Core Ontology. Furthermore, we provide a first version of a Files module [4]. Greetings, Olaf [1] http://purl.org/net/provenance/ns-20100710 [2] http://purl.org/net/provenance/ns-20100710.html#sec-changes [3] http://sourceforge.net/apps/mediawiki/trdf/nfs/project/t/tr/trdf/7/7a/ProvenanceVocabularyOverview.png [4] http://purl.org/net/provenance/files |
From: Olaf H. <ha...@in...> - 2010-07-12 17:01:41
|
Hey Jun, On Monday 12 July 2010 11:04:09 Jun Zhao wrote: > HI Olaf, > > I agree with you that it is not a good style to refer to two different > namespaces in a property domain. > > How about keeping prv:File in the core and all other file-related > properties in the file module, such as prvFiles:usedCreationGuideFile, > prvFiles:usedFile? > > Does it work? Yes, this would work. I will try to implement it. Thanks, Olaf > -- Jun > > Olaf Hartig wrote: > > Hey Jun, > > > > I'm currently trying to separate the file-related stuff from the core > > ontology and move it to a new file for the files module. Unfortunately, > > this causes the following problems: we currently have > > > > prv:createdBy rdfs:domain > > > > [ rdf:type owl:Class ; > > > > owl:unionOf ( prv:DataItem prv:File ) > > ] . > > > > The domain of prv:createdBy contains prv:File to enable users to describe > > file- based data creations easily (i.e. without the need to explicitly > > introduce the the data item that has been produced and the relationship > > between this data item and the file with which it has been created). > > > > If I now move prv:File to the files module (i.e. introducing > > prvFiles:File) we could replace the above definition by this: > > > > prv:createdBy rdfs:domain > > > > [ rdf:type owl:Class ; > > > > owl:unionOf ( prv:DataItem prvFiles:File ) ] > > . > > > > However, I think we shouldn't do this because it's not good style to > > refer to an additional module in the core. > > Furthermore, we have a similar problem if we add prvFiles:File to the > > domain of the prv:retrievedBy property as I suggested. > > > > For these reasons I guess I change my opinion: it's not a good idea to > > separate the file-related stuff into an additional module. Instead, I > > guess we have to stick with having the file-related stuff in the core. > > Hence, I will keep it in the new version that I'm going to create. Okay? > > > > Greetings, > > Olaf |
From: Jun Z. <jun...@zo...> - 2010-07-12 09:04:18
|
HI Olaf, I agree with you that it is not a good style to refer to two different namespaces in a property domain. How about keeping prv:File in the core and all other file-related properties in the file module, such as prvFiles:usedCreationGuideFile, prvFiles:usedFile? Does it work? -- Jun Olaf Hartig wrote: > Hey Jun, > > I'm currently trying to separate the file-related stuff from the core ontology > and move it to a new file for the files module. Unfortunately, this causes the > following problems: we currently have > > prv:createdBy rdfs:domain > [ rdf:type owl:Class ; > owl:unionOf ( prv:DataItem prv:File ) ] . > > The domain of prv:createdBy contains prv:File to enable users to describe file- > based data creations easily (i.e. without the need to explicitly introduce the > the data item that has been produced and the relationship between this data > item and the file with which it has been created). > > If I now move prv:File to the files module (i.e. introducing prvFiles:File) we > could replace the above definition by this: > > prv:createdBy rdfs:domain > [ rdf:type owl:Class ; > owl:unionOf ( prv:DataItem prvFiles:File ) ] . > > However, I think we shouldn't do this because it's not good style to refer to > an additional module in the core. > Furthermore, we have a similar problem if we add prvFiles:File to the domain > of the prv:retrievedBy property as I suggested. > > For these reasons I guess I change my opinion: it's not a good idea to > separate the file-related stuff into an additional module. Instead, I guess we > have to stick with having the file-related stuff in the core. Hence, I will keep > it in the new version that I'm going to create. Okay? > > Greetings, > Olaf > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > trdf-prv-vocab-users mailing list > trd...@li... > https://lists.sourceforge.net/lists/listinfo/trdf-prv-vocab-users |
From: Olaf H. <ha...@in...> - 2010-07-09 17:37:23
|
Hey Jun, I'm currently trying to separate the file-related stuff from the core ontology and move it to a new file for the files module. Unfortunately, this causes the following problems: we currently have prv:createdBy rdfs:domain [ rdf:type owl:Class ; owl:unionOf ( prv:DataItem prv:File ) ] . The domain of prv:createdBy contains prv:File to enable users to describe file- based data creations easily (i.e. without the need to explicitly introduce the the data item that has been produced and the relationship between this data item and the file with which it has been created). If I now move prv:File to the files module (i.e. introducing prvFiles:File) we could replace the above definition by this: prv:createdBy rdfs:domain [ rdf:type owl:Class ; owl:unionOf ( prv:DataItem prvFiles:File ) ] . However, I think we shouldn't do this because it's not good style to refer to an additional module in the core. Furthermore, we have a similar problem if we add prvFiles:File to the domain of the prv:retrievedBy property as I suggested. For these reasons I guess I change my opinion: it's not a good idea to separate the file-related stuff into an additional module. Instead, I guess we have to stick with having the file-related stuff in the core. Hence, I will keep it in the new version that I'm going to create. Okay? Greetings, Olaf |