Re: Contd: [pedantic-web] question about sioc / foaf usage

Peter Ansell wrote:
> 2009/12/1 Hogan, Aidan <aidan.hogan@deri.org>:
>   
>> Hi Kingsley,
>>
>>     
>>> For the sake of others.
>>>
>>> How do you describe and information resource via an RDF graph that is
>>> supposed to play well with Linked Data principles?
>>>       
>> If I understand the intent of your question, you are asking how an
>> information resource should be identified -- i.e., what's a suitable
>> URI? To clarify first: what's wrong with -- e.g. -- simply [1]? For me,
>> this fits well with [2]. How does it not play well with Linked Data
>> principles? Referring back to earlier:
>>
>>     
>>> using [1] as the information-resource URI to represent the document
>>> returned is perfectly okay according to linked data principles:
>>>
>>>    1. Use URIs as names for things [yep]
>>>    2. Use HTTP URIs so that people can look up those names. [yep]
>>>    3. When someone looks up a URI, provide useful information, using
>>> the standards (RDF, SPARQL) [yep]
>>>    4. Include links to other URIs so that they can discover more
>>>       
>> things.
>>     
>>> [not directly applicable]
>>>       
>> Cheers,
>> Aidan
>>
>> [1] http://johnbreslin.com/blog/index.php?sioc_type=site
>> [2] http://www.w3.org/TR/webarch/#id-resources
>>
>>
>>     
>
> My impression of the entire debacle is that it is designed to make
> sure that every document has at least two identifiers so that
> reasoning systems do not have to distinguish between details about the
> delivery of the document, and details contained in the document. Some
> rdf harvesting engines want to be able to say <URL>
> <retrievedWithhttpStatusCode> "200", for example, and the flow on
> effect is that you now apparently can't use the documents URL for any
> other purpose because the extra httpStatusCode triple may get added
> into the RDF store without a different graph URI. If the statements
> are merged in a single graph, there is no way to separate it after
> that point because reasoning engines, in this case description logics,
> weren't designed with this multiplicity in mind. Interestingly,
> everyone is okay with adding <URL> <retrievedWithhttpStatusCode>
> "303", because that particular magic value is judged to be immaterial
> to the nature of the URL.
>
> That is just my impression of the underlying cause for this entire
> debacle without any of the philosophical details about the nature of
> the document etc., that always pop up.
>   
Peter,

My real grip comes down to the fact that there seems to be an unwritten 
rule re. Documents i.e., they aren't material data objects (entities, 
data items, resources) re. RDF. Proof of this rule is demonstrated by 
the plethora of RDF files that don't assert any relationship between the 
RDF file (Data Container) and its structured content (Data Items).

In addition, re. the  HTTP system that drives the Web, when you issue an 
HTTP GET against a resource (i.e. a file; I don't buy the Information 
Resource moniker one bit), a server issues a 200 OK to indicate its 
ability to serve a User Agent the resource it requested. Naturally, this 
isn't how a Data Identifier works, since Identifiers are independent of: 
location, values, structure (this are very old Identity principles from 
way before the Web), you have a 303 if the Identifier looks like a 
normal resource URL or you leverage the Fragment Identifier component of 
the URL by taking the remainder of the URL as the address of the 
document containing the description of the HTTP URIs referent.

Thus, as I've stated before (elsewhere), in my world view, all data 
objects are equal i.e., if something is worth describing (e.g. a 
Document or Data Container or File), it deserves an Identifier, and in 
the context of HTTP based data networks -what Linked Data is about - it 
means: a Generic HTTP scheme URI.

I assume you've noticed the dearth of RDF examples that include 
descriptions of RDF files that are distinct, but connected, to the file 
contents.


> Cheers,
>
> Peter
>
>
>   


-- 


Regards,

Kingsley Idehen       Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO 
OpenLink Software     Web: http://www.openlinksw.com

Received on Monday, 30 November 2009 22:02:12 UTC