Re: National Identification Number URIs ( NIN URIs )
Peter, It is a good thing that the subject URI is an HTTP URI available from your server but that is only the start of the story. The rest of the story needs other servers to give your data more context. In your example the fact that there is a link can only be figured out using some external service that knows about both data sources. Sure. Before I can add a link to any data set, I have to detect it using some heuristics. Shared URN/DOI/... identifiers seem a valid approach for this -- think of ISBN numbers. Sharing identifiers is a good idea, but it isn't Linked Data as yet... I'm talking of the *preconditions* for linking data, based on shared identifiers. And once I have these identifiers, why not publish them alongside the dereferenceable URIs. If your server was Linked Data and not just an HTTP URI based RDF database then it would link out using HTTP URI's and both servers could be directly explored without some external service. Once the link has been detected, I can of course add it to both data sets. Well, the owner of the datasets can. This is Linked Data, when the dataset owners discover the mutual references and link out from their HTTP URI's to the other datasets HTTP URI's. Why only the dataset owners? A third party that is aware of both data sets is enabled to discover these links, too. It was enabled by sharing the property, and then having others discover it. Just sharing the URN property isn't Linked Data as people have no way of resolving the URN that is referenced to more information. Again, it's a precondition to link data. It could also have been shared in another way using Inverse Functional Properties (IFP) so that the URN scheme need not have been created. The URN schema for ISBN already exists [1], and several others exist (e.g., SWIFT [2]), why should we throw them away? [1] http://www.faqs.org/rfcs/rfc3187.html [2] http://www.faqs.org/rfcs/rfc3615.html There is no automatic HTTP based way of knowing which datasets may have relevant links in either case, One could use indices to find other occurrences of the same URN. When they are linked via owl:sameAs, the linking can be fully automatized. so serving up the statements on your dataset is very useful for discovery, I wasn't meaning to say that was a bad thing. Just emphasising the full story for Linked Data. I got that :-) My point is simply that not *every* URI in a Linked Data context needs to be dereferenceable. When there are established URN schemes in place (like it is the case for ISBN numbers), why not reuse them instead of packing them in a literal (is there a datatype for ISBN numbers?) and publish them to simplify linking for others? This seems to make more sense to me than only relying on URN-to-HTTPURI mappings, which I can still do, as long as I publish the original identifier in its native URN form. Best Bernhard
Extended Deadline: Call for Papers I-Semantics 2010
*** EXTENDED DEADLINE MARCH 25th 2010 *** Call for Papers I-Semantics 2010: 6th International Conference on Semantic Systems Graz, Austria, 1 - 3 September 2010 http://www.i-semantics.at including Call for Papers 5th AIS SigPrag International Conference on Pragmatic Web (ICPW 2010) Call for Submissions 3rd Triplification Challenge Latest News: Paper Submission Deadline extended to MARCH 25th I-SEMANTICS proceedings published by ACM ICPS Tim Berners-Lee official patron of Triplification Challenge 2010 Peter Gloor (MIT) to Hold Keynote at I-SEMANTICS 2010 Prof. Marti Hearst gives a Keynote at I-SEMANTICS �10 Elsevier Data Knowledge Engineering on �Pragmatic Web� forthcoming Scope = I-SEMANTICS 2010 (www.i-semantics.at) is the 6th conference in the I-SEMANTICS series and provides a forum for academic and industrial research development that focuses on semantic technologies and the Semantic Web. I-SEMANTICS 2010 will bring together both researchers and practitioners in the areas of Linked Data, Social Software and the Semantic Web in order to present and develop innovative ideas that help realising the �Social Semantic Web� and the �Corporate Semantic Web�. I-SEMANTICS 2010 will be the host of this year`s regional Pragmatic Web Conference as well as the third edition of the TRIPLIFICATION Challenge. Further on I-SEMANTICS will be complemented by I-KNOW (www.i-know.at), the 10th International Conference on Knowledge Management. This setup is aiming to reflect the increasing importance and convergence of knowledge management and semantic systems. Topics == The special focus of I-SEMANTICS 2010 is �Towards a Web of Linked Data�. As a conference aiming to bring together science and industry, I-SEMANTICS encourages both, scientific (research/application) and industrial contributions. The following table summarises the topics we are interested in: Web of Data and Linked Data --- � Triplification of existing data � Vocabularies, taxonomies and schemas for use on the Web of Data � Querying, searching and browsing over Linked Data � Coreference detection and dataset reconciliation � Information provenance and quality assessment on the Web of Data � User interaction and visualisation � Applications utilizing open data sets � Linked Enterprise Data, Linked Government Data Corporate Semantic Web -- � Corporate thesauri, corporate business vocabularies / ontologies and business rules � Semantic Business Information Systems � Semantic Business Process Management � Semantic Decision Management � Semantics, Pragmatics and Semiotics in Organizations � Economic and entrepreneurial aspects and business models of Semantic Enterprises Semantic Social Software � Semantic blogging, wikis and content management systems � Semantic Desktop � Semantic mashups � Semantic/structured tagging � Social semantic web and mobile services Semantic Content Engineering � Ontology Engineering Ontology Merging � Ontology Design Patterns � Ontology Life Cycle Management � Ontology Learning � Linguistic and statistic approaches (text-mining, NLP, etc.) for structuring and extracting content and entities � Automated annotation, extreme tagging and digital curation approaches Building Blocks for Semantic Web Applications - � Scalable inference, retrieval, and persistence of semantic data � Design processes from requirements to maintenance � Design patterns, Best practices and Reference Models � User-interface components, template languages � Integration of distributed repositories � Policy Awareness Policy Aware Web � Semantic web services Studies, Metrics Benchmarks - � Case studies of and benchmarks in semantic systems usage � Evaluation perspectives, methods and Semantic Web research methodologies � Technology assessment, accepta nce/media choice theories � Usability and user interaction with semantic technologies � Quality analysis of socially generated semantic content � Trust and privacy issues in semantic applications � Economic effects generated by large scale semmantic systems Pragmatic Web Track === The Conference on PRAGMATIC WEB is centered around the study of �pragmatics� in the Semantic Web. That is, it draws attention to how communicative actions with a pragmatic context are performed via Web media and illuminates how mutual understanding and commitments to actions can evolve in conversations. For further information about the Pragmatic Web see http://www.pragmaticweb.info/ Topics of Interest -- � Pragmatic Web Science � Theories, Frameworks, Models and Methods �inspired
Re: National Identification Number URIs ( NIN URIs )
I have found this a very interesting discussion, thinking about the Linked Data World at large as well as what others think - thanks. Sorry this moved away from the important discussion about how to identify people, both as a technical and a socio issue - my fault. On 09/03/2010 09:12, Bernhard Schandl bernhard.scha...@univie.ac.at wrote: Peter, It is a good thing that the subject URI is an HTTP URI available from your server but that is only the start of the story. The rest of the story needs other servers to give your data more context. In your example the fact that there is a link can only be figured out using some external service that knows about both data sources. Sure. Before I can add a link to any data set, I have to detect it using some heuristics. Shared URN/DOI/... identifiers seem a valid approach for this -- think of ISBN numbers. Sharing identifiers is a good idea, but it isn't Linked Data as yet... I'm talking of the *preconditions* for linking data, based on shared identifiers. And once I have these identifiers, why not publish them alongside the dereferenceable URIs. Being able to work out what a dereferenceable URI means is indeed a pre-condition for linking data, and also in the Linked Data, this is achieved by dereferencing and examining the RDF returned. And finding a URN, doi, isbn, mailto, etc. is a very good way of communicating that information. However, for me in the Linked Data world, such URIs are no more an *identifier* than Hugh Glaser, or the title of a book, (or even the URL of one of my homepages) simply because the access mechanism is unclear, and even if I do try to look it up I am unlikely to get RDF (at least at present). They are more useful in general, of course, because they are less likely to be ambiguous, but it is only a matter of degree. If your server was Linked Data and not just an HTTP URI based RDF database then it would link out using HTTP URI's and both servers could be directly explored without some external service. Once the link has been detected, I can of course add it to both data sets. Well, the owner of the datasets can. This is Linked Data, when the dataset owners discover the mutual references and link out from their HTTP URI's to the other datasets HTTP URI's. Why only the dataset owners? A third party that is aware of both data sets is enabled to discover these links, too. I agree entirely, although the dataset owner is in a prime position to seed the activity, and also may have other implicit knowledge that is useful to help to get the links right. It was enabled by sharing the property, and then having others discover it. Just sharing the URN property isn't Linked Data as people have no way of resolving the URN that is referenced to more information. Again, it's a precondition to link data. It could also have been shared in another way using Inverse Functional Properties (IFP) so that the URN scheme need not have been created. The URN schema for ISBN already exists [1], and several others exist (e.g., SWIFT [2]), why should we throw them away? [1] http://www.faqs.org/rfcs/rfc3187.html [2] http://www.faqs.org/rfcs/rfc3615.html There is no automatic HTTP based way of knowing which datasets may have relevant links in either case, One could use indices to find other occurrences of the same URN. When they are linked via owl:sameAs, the linking can be fully automatized. so serving up the statements on your dataset is very useful for discovery, I wasn't meaning to say that was a bad thing. Just emphasising the full story for Linked Data. I got that :-) My point is simply that not *every* URI in a Linked Data context needs to be dereferenceable. When there are established URN schemes in place (like it is the case for ISBN numbers), why not reuse them instead of packing them in a literal (is there a datatype for ISBN numbers?) and publish them to simplify linking for others? This seems to make more sense to me than only relying on URN-to-HTTPURI mappings, which I can still do, as long as I publish the original identifier in its native URN form. I have a feeling that the issue here may be the same as how to represent the address of someone's pure html home page in RDF. It is a URL and hence a URI. But it is not dereferenceable to RDF. A purist might say that it is not a Linked Data URI (doesn't return RDF), and so should be a string, hopefully with a useful type on it. But for others it is a resource, and so can comfortably be a URI in RDF. And having it as a resource enables it to be used in a more convenient way for the sort of thing that we are discussing. So dereferencing one of your Linked Data URIs will return some RDF that has resources (URIs) that are not dereferenceable to RDF. And these will be very helpful to people/agents who are trying to add linking to the world. Hopefully that is sufficiently closely related to your comments to make sense? And I
JISC Grant Funding for Linked Data
I just noticed that a recent JISC Grant Funding Call [1] includes some funding available for Linked Data publishing projects by higher education institutions in the UK: Strand B - Expose Projects that enable content to be made available on the Web using structured data, in particular linked data which increases its potential value to researchers, teachers and learners. Total funds: £750,000. Up to 20 projects will be funded. Maximum funding for any one project is £100,000. A Briefing Document is available alongside this call, which outlines key background and scope information to which bidders should refer. The deadline for receipt of proposals in response to this call is 12 noon UK time on Tuesday 20 April 2010. //Ed [1] http://www.jisc.ac.uk/fundingopportunities/funding_calls/2010/03/210depositexpose.aspx
How to handle HTTP 301, 410
Hi All, I'm mainly wondering.. what the Linked Data implications of the following are: 301 Moved Permanently The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the request-target to one or more of the new references returned by the server, where possible. [1] 410 Gone The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the request-target after user approval. [2] Many Regards, Nathan [1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-08#section-8.3.2 [2] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-08#section-8.4.11
Re: National Identification Number URIs ( NIN URIs )
Hugh Glaser wrote: I have found this a very interesting discussion, thinking about the Linked Data World at large as well as what others think - thanks. Sorry this moved away from the important discussion about how to identify people, both as a technical and a socio issue - my fault. Hugh, Nice discussion, I don't think anyone found it divergent or distracting :-) As per usual, you triggered broader discussion of some issues that have been rumbling under the surface for a while. I am sure Aldo is much clear about options for easy generation of Identifiers etc.. Kingsley On 09/03/2010 09:12, Bernhard Schandl bernhard.scha...@univie.ac.at wrote: Peter, It is a good thing that the subject URI is an HTTP URI available from your server but that is only the start of the story. The rest of the story needs other servers to give your data more context. In your example the fact that there is a link can only be figured out using some external service that knows about both data sources. Sure. Before I can add a link to any data set, I have to detect it using some heuristics. Shared URN/DOI/... identifiers seem a valid approach for this -- think of ISBN numbers. Sharing identifiers is a good idea, but it isn't Linked Data as yet... I'm talking of the *preconditions* for linking data, based on shared identifiers. And once I have these identifiers, why not publish them alongside the dereferenceable URIs. Being able to work out what a dereferenceable URI means is indeed a pre-condition for linking data, and also in the Linked Data, this is achieved by dereferencing and examining the RDF returned. And finding a URN, doi, isbn, mailto, etc. is a very good way of communicating that information. However, for me in the Linked Data world, such URIs are no more an *identifier* than Hugh Glaser, or the title of a book, (or even the URL of one of my homepages) simply because the access mechanism is unclear, and even if I do try to look it up I am unlikely to get RDF (at least at present). They are more useful in general, of course, because they are less likely to be ambiguous, but it is only a matter of degree. If your server was Linked Data and not just an HTTP URI based RDF database then it would link out using HTTP URI's and both servers could be directly explored without some external service. Once the link has been detected, I can of course add it to both data sets. Well, the owner of the datasets can. This is Linked Data, when the dataset owners discover the mutual references and link out from their HTTP URI's to the other datasets HTTP URI's. Why only the dataset owners? A third party that is aware of both data sets is enabled to discover these links, too. I agree entirely, although the dataset owner is in a prime position to seed the activity, and also may have other implicit knowledge that is useful to help to get the links right. It was enabled by sharing the property, and then having others discover it. Just sharing the URN property isn't Linked Data as people have no way of resolving the URN that is referenced to more information. Again, it's a precondition to link data. It could also have been shared in another way using Inverse Functional Properties (IFP) so that the URN scheme need not have been created. The URN schema for ISBN already exists [1], and several others exist (e.g., SWIFT [2]), why should we throw them away? [1] http://www.faqs.org/rfcs/rfc3187.html [2] http://www.faqs.org/rfcs/rfc3615.html There is no automatic HTTP based way of knowing which datasets may have relevant links in either case, One could use indices to find other occurrences of the same URN. When they are linked via owl:sameAs, the linking can be fully automatized. so serving up the statements on your dataset is very useful for discovery, I wasn't meaning to say that was a bad thing. Just emphasising the full story for Linked Data. I got that :-) My point is simply that not *every* URI in a Linked Data context needs to be dereferenceable. When there are established URN schemes in place (like it is the case for ISBN numbers), why not reuse them instead of packing them in a literal (is there a datatype for ISBN numbers?) and publish them to simplify linking for others? This seems to make more sense to me than only relying on URN-to-HTTPURI mappings, which I can still do, as long as I publish the original identifier in its native URN form. I have a feeling that the issue here may be the same as how to represent the address of someone's pure html home page in RDF. It is a URL and hence a URI. But it is not dereferenceable to RDF. A purist might say that it is not a Linked Data URI (doesn't return RDF), and so should be a string, hopefully with a useful type on it. But for others it is a resource, and so can comfortably be a URI in RDF. And having it as a resource
Re: How to handle HTTP 301, 410
Nathan wrote: Hi All, I'm mainly wondering.. what the Linked Data implications of the following are: 301 Moved Permanently The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the request-target to one or more of the new references returned by the server, where possible. [1] Representation of Data Object Description has new URL. Based on this response, the calling user agent *may* update its local relation between Data Object and the URL of the Resource that bears its Description (Representation). This is where an explicit isDescribeBy relation comes in handy re. Object Identifier association with Resource bearing its Description. 410 Gone The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the request-target after user approval. [2] Representation of Data Object Description is no longer available here. I also have no clue as to if such a thing exists elsewhere. Based on this response, the calling user agent *may* decide to discard all references to this Data Object. Kingsley Many Regards, Nathan [1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-08#section-8.3.2 [2] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-08#section-8.4.11 -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: How to handle HTTP 301, 410
Kingsley Idehen wrote: Nathan wrote: Hi All, I'm mainly wondering.. what the Linked Data implications of the following are: 301 Moved Permanently The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the request-target to one or more of the new references returned by the server, where possible. [1] Representation of Data Object Description has new URL. Based on this response, the calling user agent *may* update its local relation between Data Object and the URL of the Resource that bears its Description (Representation). This is where an explicit isDescribeBy relation comes in handy re. Object Identifier association with Resource bearing its Description. I really think isDescribedBy is a good idea for many reasons, in this context I'm unsure though (more below). Unsure with regards Representation of Data Object Description has new URL as the documentation is pretty explicit in saying resource has been assigned a new permanent URI. For instance if I changed by WebID and moved my FOAF profile at some point in the future I would potentially see this as a mechanism of informing all those who deference my old WebID about my new WebID, with the additional note that they should now use new URI as by WebID. I guess I'd probably expect people to create something like newid replaces oldid; and then use new from here on.. 410 Gone The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the request-target after user approval. [2] Representation of Data Object Description is no longer available here. I also have no clue as to if such a thing exists elsewhere. Based on this response, the calling user agent *may* decide to discard all references to this Data Object. as above
Re: How to handle HTTP 301, 410
Nathan wrote: Kingsley Idehen wrote: Nathan wrote: Hi All, I'm mainly wondering.. what the Linked Data implications of the following are: 301 Moved Permanently The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the request-target to one or more of the new references returned by the server, where possible. [1] Representation of Data Object Description has new URL. Based on this response, the calling user agent *may* update its local relation between Data Object and the URL of the Resource that bears its Description (Representation). This is where an explicit isDescribeBy relation comes in handy re. Object Identifier association with Resource bearing its Description. I really think isDescribedBy is a good idea for many reasons, in this context I'm unsure though (more below). Unsure with regards Representation of Data Object Description has new URL as the documentation is pretty explicit in saying resource has been assigned a new permanent URI. In my world view: Resources have URLs while Data Objects have Generic HTTP URIs. I believe you can have Data Object ID: http://dbpedia.org/resource/data-object Described by a Resource at: http://dbpedia.org/page/data-object . So if http://dbpedia.org/page/data-object changes, the UA can update its local cache or store or whatever mechanism it uses to handle interaction with Data Objects with Identifiers that resolve to Description bearing Resource Locations. For instance if I changed by WebID and moved my FOAF profile at some point in the future I would potentially see this as a mechanism of informing all those who deference my old WebID about my new WebID, with the additional note that they should now use new URI as by WebID. WebID (a Data Object Identifier) is Referenced by your FOAF Profile Document (a Resource at a location). I guess I'd probably expect people to create something like newid replaces oldid; and then use new from here on.. Yes, but try to be clear about what's changing here. Is it the Data Object Idenfifier or the location of its Resource bearing Description. Identifiers (irrespective of whether they resolve or not must be distinct from the things they are associated with). Kingsley 410 Gone The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the request-target after user approval. [2] Representation of Data Object Description is no longer available here. I also have no clue as to if such a thing exists elsewhere. Based on this response, the calling user agent *may* decide to discard all references to this Data Object. as above -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: isDescribedBy breaks Linked Data
Nathan wrote: Hi All, Admittedly a rather bold subject line, but I was just thinking about the often suggested usage of isDescribedBy for associating a subject with a resource describing it, and whilst good for RDF it appears to break Linked Data from what I can see.. consider: http://example.org/a#t dcterms:relation http://nowgone.org/b#t . Of course that's broken, but it has nothing to do with isDescribeBy, its the triple in question at fault :-) @prefix wdrs: http://www.w3.org/2007/05/powder-s# http://dbpedia.org/resource/Linked_Data wdrs:describedby http://dbpedia.org/page/Linked_Data#this . Linked Data breaks if we assume Documents aren't Data Objects in their own right, and then assume that URLs suffice as their Identifiers. Yes, in this case it does break, hence the twister of a triple above (note the #this object of a slash URI based subject in the relation above). Note: Link: response from server can also unveil the Data Object and Description bearing Resource relation. Just as the doc could carry same info in link/. Trouble is that nowgone.org is now gone; and there is no way to dereference the data to find out what http://nowgone.org/b#t When someone looks up a URI, provide useful information, using the standards, of course the very fact the information is gone breaks this Linked Data guideline, and whilst the subject of this mail was a bit over the top; I would like to make it clear that (imho) using isDescribedBy as a workaround to say that the description of subject is now available here simply won't work; because you can't dereference the subject to get that all important triple! I hope I didn't say or imply: using isDescribedBy *is* a workaround to say that the description of subject is now available. I hope I implied: wdrs:describedby is a good property for the relation that connects a Data Objects to a Resource bearing its Description. Re. Data Object Reference availability, its depends on where the loss of visibility occurs. If looking at the Web of Linked Data in general, erasing an Identifiers will be hard (i.e. across all Subject or Objects slots in a Web Scale Distributed Graph). See: curl -I -H Accept: text/html http://dbpedia.org/resource/Linked_Data HTTP/1.1 303 See Other Server: Virtuoso/06.01.3127 (Solaris) x86_64-sun-solaris2.10-64 VDB Connection: close Content-Type: text/html; charset=ISO-8859-1 Date: Tue, 09 Mar 2010 16:31:49 GMT Accept-Ranges: bytes Link: http://mementoarchive.lanl.gov/dbpedia/timegate/http://dbpedia.org/resource/Linked_Data; rel=timegate Location: http://dbpedia.org/page/Linked_Data Content-Length: 0 What about: http://mementoarchive.lanl.gov/dbpedia/timegate/http://dbpedia.org/resource/Linked_Data (note: when its live and functional) ditto other places that have accessed and stored the Representation of the Description of said Data Object? As far as I can tell, in order to keep everything dereferencable when URIs change, the URI itself must be changed where ever possible. When a Data Object Identifier that is inextricably bound to its Description bearing Resource URL changes, then you have two things to change. Otherwise, its one or the other. Thus I guess I would like to get thoughts on how this very real scenario of sites dropping / relocating can be addressed in Linked Data terms; and what can be leveraged to communicate the changing or removal of URIs (!) and documents describing them. Real example: Consider flashden.net which is a long lived, stable site and will be for years to come - for legal reasons they've had to change their name and domain to activeden.net - had this been 2 years down the line when they'd also be publishing linked data this could cause a real problem. They would *have* to change all their URIs. Shove the triples in an new RDF store capable of deploying Linked Data and make the appropriate URL re-write rules, with regards to new location. As for the old location, if legally usable: put 301's in place, beyond that the Linked Data archive service providers and Google cache are the only options I know of. Many Regards! Nathan -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: National Identification Number URIs ( NIN URIs )
Bernhard and Hugh, On 9 March 2010 21:37, Hugh Glaser h...@ecs.soton.ac.uk wrote: I have found this a very interesting discussion, thinking about the Linked Data World at large as well as what others think - thanks. Sorry this moved away from the important discussion about how to identify people, both as a technical and a socio issue - my fault. Although we are currently discussing using the ISBN example I think it is still relevant to the thread as identifiers for people are possibly better shared as URN's since to create standardised HTTP URI's might imply that a particular organisation has taken over that persons identity which may not fit so well with the privacy issues. On 09/03/2010 09:12, Bernhard Schandl bernhard.scha...@univie.ac.at wrote: Peter, It is a good thing that the subject URI is an HTTP URI available from your server but that is only the start of the story. The rest of the story needs other servers to give your data more context. In your example the fact that there is a link can only be figured out using some external service that knows about both data sources. Sure. Before I can add a link to any data set, I have to detect it using some heuristics. Shared URN/DOI/... identifiers seem a valid approach for this -- think of ISBN numbers. Sharing identifiers is a good idea, but it isn't Linked Data as yet... I'm talking of the *preconditions* for linking data, based on shared identifiers. And once I have these identifiers, why not publish them alongside the dereferenceable URIs. I think this one is partly a precondition and partly a useful outcome in semantic terms. You can get access to the item better if there are third parties or generic query interfaces available as a precondition. However, then you also portray your data in terms of the community defined URN scheme, similar to putting your data in the context of an ontology that is understood by many people. Being able to work out what a dereferenceable URI means is indeed a pre-condition for linking data, and also in the Linked Data, this is achieved by dereferencing and examining the RDF returned. And finding a URN, doi, isbn, mailto, etc. is a very good way of communicating that information. However, for me in the Linked Data world, such URIs are no more an *identifier* than Hugh Glaser, or the title of a book, (or even the URL of one of my homepages) simply because the access mechanism is unclear, and even if I do try to look it up I am unlikely to get RDF (at least at present). They are more useful in general, of course, because they are less likely to be ambiguous, but it is only a matter of degree. If your server was Linked Data and not just an HTTP URI based RDF database then it would link out using HTTP URI's and both servers could be directly explored without some external service. Once the link has been detected, I can of course add it to both data sets. Well, the owner of the datasets can. This is Linked Data, when the dataset owners discover the mutual references and link out from their HTTP URI's to the other datasets HTTP URI's. Why only the dataset owners? A third party that is aware of both data sets is enabled to discover these links, too. I agree entirely, although the dataset owner is in a prime position to seed the activity, and also may have other implicit knowledge that is useful to help to get the links right. If other users identify the links they have to communicate their knowledge back to the dataset owners to complete the Linked Data circle, unless you include searching on indicies as part of the Linked Data circle. If the third party publishes the information it may not be Linked Data, as they may choose to make up a triple that doesn't contain any URI's that resolve to their data... Resolving the following triple on http://thirdparty.com/mypage is not Linked Data IMO, but it could be if they make up a different structure to represent the link. http://myserver.com/urn:isbn:1232-132132-1 linksto http://otherserver.com/urn:isbn:1232-132132-1 . It was enabled by sharing the property, and then having others discover it. Just sharing the URN property isn't Linked Data as people have no way of resolving the URN that is referenced to more information. Again, it's a precondition to link data. It could also have been shared in another way using Inverse Functional Properties (IFP) so that the URN scheme need not have been created. The URN schema for ISBN already exists [1], and several others exist (e.g., SWIFT [2]), why should we throw them away? [1] http://www.faqs.org/rfcs/rfc3187.html [2] http://www.faqs.org/rfcs/rfc3615.html There is no automatic HTTP based way of knowing which datasets may have relevant links in either case, One could use indices to find other occurrences of the same URN. When they are linked via owl:sameAs, the linking can be fully automatized. so serving up the statements on your dataset is very
