[
Lists Home |
Date Index |
Thread Index
]
I would expect the syntax to work. What about the
need to prevent ambiguity? IOW, in the SGML world,
a public ID depends just like a URI on the system
that establishes it to ensure qualities such as
uniqueness. What SGML said, AFAIK, was that SGML was
not obliged to do that (there being no definitive
SGML system per se) and that someone using a public ID
should work out a system. So if the Public ID is used
in RDF for the Semantic Web, where does uniqueness
get conferred? As I understand the decision to
use URIs, it was based on getting uniqueness for
free. The problem comes of http:// being overloaded
if one stuffs it in there "in name only".
John can probably answer that and/or correct
my misunderstanding if any.
Further, there is the issue that URIs designate
representations of resources and that these can
vary over time/space/authorial_intent, etc,. and
that this conflicts with the RDF requirement for
insisting that the URI uniquely identifies one
thing.
1. What is the one thing that it identifies
for URIs?
2. Are these resources (can only be one) or
representations (can vary)?
I'm trying to understand if this is a real
problem (needs a constant; used a variable)
or a categorical error (says a resource,
but a representation is meant). IOW, given
the varying aspects of representations, it seems
that RDF really needs and wants non-varying URNs
for which urn:publicID is a possible solution
but requires a different means to enforce uniqueness.
Yes/No/Mu?
len
From: Bill de hOra [mailto:dehora@eircom.net]
> From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
>
>
> What would be the impact on RDF if it used these
> instead of URIs?
None, if we forget for a moment that RDF specifies URIs. Today,
urn:publicid: works fine for RDF, so do tag: URIs.
|
