Re: rdfms-resource-semantics

Sampo Syreeni wrote:
> 
> On Thu, 7 Jun 2001, Lee Jonas wrote:
> 
> >All this confusion over 'resource' (RFC2396 sense) and 'resource' (RDF
> >sense) is precisely why I advocate eliminating the inconsistent definition
> >of 'resource' altogether from the RDF M&S spec.
> 
> But we do need a name for what is being described. If it's 'resource', we
> need to emphasize that it's not an RFC2396 resource. If it's something else,
> it has to be defined as something identified by a URI reference.

That should be the definition of 'resource' for RDF: something
that can be subject or object of RDF statments and is 
identified by a URI reference. period. 

mathematically speaking: A set R with a function 
label: R -> URI | {*} such
that the restriction label: R -> URI is injective. 
('resources' r with label(r)=* are anonymous.). 
Nothing more to say about it.

> >Hence I suggest that the RDF spec should be changed to say that triples
> >describe whatever can be referenced by a URI reference - i.e. a 'view' or a
> >'part' of the resource identified by the URI.  At the end of the day, RDF
> >semantics would remain unchanged: triples (p, s, o) where 'p' & 's', and
> >optionally 'o', are URI references.
> 
> My thoughts exactly. One source of the confusion is that nobody has given a
> name to whatever it is that URI references point to. As we need to speak
> about the thing, RDF co-opts 'resource'. Someone suggested entity. At the
> end of the day, it doesn't really matter as long as people understand that
> RDF points by URI *references* and the things described aren't the same as
> RFC2396 'resources' even if RDF is the 'resource description framework'.

The source of the confusion is that there is no formal
mathematical model for RDF (see [1] for a quick-shot,
but there are others ...). In my opinion it doesn't matter
what a 'resource' really is, the only thing that matters is what 
RDF wants to do with it ...

Regards,
Stefan

[1]
http://lists.w3.org/Archives/Public/www-rdf-interest/2001Jun/0008.html

Received on Thursday, 7 June 2001 09:42:32 UTC