Re: [metaDataInURI-31]: Initial draft finding for public review/ comme nt.

>> The resource referred to by the URI does not vary.  What varies is the
>> target that is ultimately referred to by the "sentence" surrounding 
>> the
>> URI referral.
>
> While I generally agree with your stance on this issue (as far as I can
> tell), I am slightly concerned with this introduction of the terms 
> "target"
> of a "sentence". If not a "resource", what is such a "target"?

It is a resource, but that isn't very specific.  The noun subject of a
sentence is a resource.  So is the target of a reference.  I wasn't
trying to be definitive -- just explanatory.

> In RDF terms,
> such targets of sentences are RDF resources, sometimes so called 
> "anonymous
> resources" or "b-nodes" (blank nodes) in RDF terms. If this is what 
> you mean
> then we have a readily available formalism to work out these issues.

Granted, but do keep in mind that RDF is essentially circular -- its
definitions are inherently less grounded in real-world semantics because
it defines away the messy bits.  That makes it less interesting, IMO,
than an example that people encounter on a regular basis.  I'd rather
not introduce an artificial vocabulary that only a few people truly
understand when I am trying to give a real-world example.  But, yes,
these things are anonymous resources, or at least resources for which
we are not immediately aware of a specific URI.

...

>> That is why there is no conflict at all
>> between the references <a href="http://example.com"> and
>> <foo xmlns="http://example.com">; the context surrounding
>> the reference defines meaning by its use, not by the URI scheme.
>>
>
> Whether there is or is not a conflict depends. For example suppose 
> (edited
> for better RDF clarity) and assuming that both "href" and "xmlns" can 
> be
> considered properties (xmlns is not normally so considered, but allow 
> this
> example).
>
> <a id="A1" href="http://example.com">
> <foo id="FOO1" xmlns="http://example.com">
>
> =>
> :A1 :href <http://example.com> .
> :FOO1 :xmlns <http://example.com> .
>
> and
>
> :A1 rdf:type :a .
> :FOO1 rdf:type :foo .
> :href rdfs:range :WebSite .
> :xmlns rdfs:range :XMLNamespace .
>
> now I'd be able to conclude that
>
> http://example.com rdf:type :WebSite .
> http://example.com rdf:type :XMLNamespace .
>
> which _might be_ a contradiction if I also say that web sites and 
> namespaces
> are _disjoint_ i.e.
>
> :WebSite owl:disjointWith :XMLNamespace .

I think that is simply because of your choice of ranges, since the
range of both href and xmlns is URI.  Neither one requires that the
resource be accessible to GET.  What you could add is a behavioral
statement that given <a> contains an attribute "href", there exists
an expectation that the value of the href is a URI reference that can
be resolved to a URI that, when dereferenced with GET semantics, will
result in a representation of a website.  That is not contradictory
to the statement that the same URI, when encountered as the value of
"xmlns" within <foo>, identifies an XML Namespace.

> Bottom line: although this N3 might be painful for those of us who are 
> not
> RDF/OWL inclined, I believe it is important to try and define these 
> things
> in a precise fashion, otherwise there will be a danger of introducing 
> terms
> such as "sentence", "context" and "target" to the already muddled URI
> discussions. I do think that the RDF/OWL treatment of such issues is
> appropriate, and hope this will be considered in deciding these issues.

My opinion is that RDF/OWL descriptions are every bit as likely to be
misinterpreted, and more likely to be falsely constrained, than plain
old ambiguous language.  The problem is that a formalism does not make
statements any easier to get right -- they just make it easier for them
to be proven wrong.  And if we discuss everything in terms that only
a few people can read, let alone discover the errors within, then what
we have accomplished is simply to limit the audience.

I think it would be a better idea for me to continue writing in terms
that most people think they might understand, and let specialists
think of ways to translate that into terminology that is easier to
prove wrong.  That is better than me trying to write in N3, since
I would just create an endless amount of noise via syntactic errors.

In any case, I can't remember why this is relevant to the issue in
the subject line, so I'll shut up now.

....Roy

Received on Monday, 14 July 2003 17:15:24 UTC