Difference between revisions of "Talk:DualUseUri"

From W3C Wiki
Jump to: navigation, search
(Created page with "--~~~~ I wonder how I can tell whether a URI will lead to a page or it is pointing at the actual thing? I guess you need to paste the URI into a browser in order to see how it be…")
 
m
Line 1: Line 1:
--[[User:Mvmacke|Marcel van Mackelenbergh]] 20:54, 5 January 2013 (UTC) I wonder how I can tell whether a URI will lead to a page or it is pointing at the actual thing? I guess you need to paste the URI into a browser in order to see how it behaves (resolve or redirect). I see that dbpedia puts an extra word in the URI (e.g. resource, page, vocab). However, this brings me into the problems we had in the old world. For example a URI that points to an RDF-endppoint. Is this a resource or a page? Both I would say. But I can also defend it is neither. The point I am trying to make is that making a classification is exactly the thing we want to avoid. Am I wrong? I think with DualUseURI's we bring back the classification problem.
+
--[[User:Mvmacke|Marcel van Mackelenbergh]] 20:54, 5 January 2013 (UTC) I wonder how I can tell whether a URI will lead to a page or it is pointing at the actual thing? I guess you need to paste the URI into a browser in order to see how it behaves (resolve or redirect). I see that dbpedia puts an extra word in the URI (e.g. resource, page, vocab). However, this brings me into the problems we had in the old world. For example a URI that points to an RDF-endpoint. Is this a resource or a page? Both I would say. But I can also defend it is neither. The point I am trying to make is that making a classification is exactly the thing we want to avoid. Am I wrong? I think with DualUseURI's we bring back the classification problem.
  
 
A colleague of mine has an alternative great idea: put the identification of the 'real world thing' in the last part of the URI, combine this with the 'resolve'-part of the URI and you get a URI that provides an explanation about the last part. Yes, this would mean that you get twice "http" in a URI that talks about a webpage. Is that a problem? In that way we never need to think about DualUsedURI's. I am pretty enthousiastic about this idea.
 
A colleague of mine has an alternative great idea: put the identification of the 'real world thing' in the last part of the URI, combine this with the 'resolve'-part of the URI and you get a URI that provides an explanation about the last part. Yes, this would mean that you get twice "http" in a URI that talks about a webpage. Is that a problem? In that way we never need to think about DualUsedURI's. I am pretty enthousiastic about this idea.

Revision as of 21:06, 5 January 2013

--Marcel van Mackelenbergh 20:54, 5 January 2013 (UTC) I wonder how I can tell whether a URI will lead to a page or it is pointing at the actual thing? I guess you need to paste the URI into a browser in order to see how it behaves (resolve or redirect). I see that dbpedia puts an extra word in the URI (e.g. resource, page, vocab). However, this brings me into the problems we had in the old world. For example a URI that points to an RDF-endpoint. Is this a resource or a page? Both I would say. But I can also defend it is neither. The point I am trying to make is that making a classification is exactly the thing we want to avoid. Am I wrong? I think with DualUseURI's we bring back the classification problem.

A colleague of mine has an alternative great idea: put the identification of the 'real world thing' in the last part of the URI, combine this with the 'resolve'-part of the URI and you get a URI that provides an explanation about the last part. Yes, this would mean that you get twice "http" in a URI that talks about a webpage. Is that a problem? In that way we never need to think about DualUsedURI's. I am pretty enthousiastic about this idea.