Peter Ansell wrote:
2009/12/1 Hogan, Aidan <aidan.ho...@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
