Re: Conneg representation equivalence

Kingsley Idehen wrote:
> For simplicity sake, just at "#this" to the following URLs and then 
> reevaluate the model i.e, <http://example.org/index.en.html#this> which 
> is the primary resource (a representation of the document which is 
> basically a container) associated with a secondary resource (a 
> representation of what the document is about). At the current time, your 
> modeling discards the container i.e., treats resource "index.html" as 
> none existent by describing it using properties of its content.

Okay. I mostly understand what you're saying here, but it's not clear
which URI you assign to the container in the end--is it
<index.en.html#this> or <index.en.html>? To me, the former seems a
better choice, because it complies with the established Linked Data
practice of asserting dcterms:creator etc. on the very same URLs that we
type into the location bars of our browsers. So we could have:

	</index.en.html>
		a foaf:Document ;
		dcterms:creator </id/joe> ;
		dcterms:blahblah ... .

	</index.en.html#this>
		a http:Container ;
		http:hasContent </index.en.html> .

Is there an already existing vocabulary to use in such a scenario? the
one that I designated with prefix "http:" in this snippet?

Also, I must add that this practice of distinguishing between content
and container doesn't seem to be used widely in the current web of
Linked Data, so people mostly "discard the container" as you say.

-- 
Vasiliy Faronov

Received on Sunday, 21 March 2010 12:26:10 UTC