On 11/12/10 9:18 AM, Lars Heuer wrote:
Hi Kingsley,
[...]
identity problem. Unless we'd introduce a concept to distinguish
between NIRs and IRs (like Topic Maps does with Subject Identifiers
and Subject Locators).
Topic Maps isn't doing anything that isn't being done via Linked Data
patterns, already. I've never groked this generally held position from
Topic Maps community.
I speak about the NIR vs. IR problem. Topic Maps provides one possible
solution for it (without status codes). That's all.
Status codes are a suboptimal solution, imo.
Suboptimal for disambiguation at the content level. Okay when it comes
to disambiguating Name or Address with regards to an HTTP request IRI.
An example:
<http://www.amazon.com/Identity-Crisis-Brad-Meltzer/dp/1401204589/>
returns 200 with no machine-readable data (like RDFa).
Methinks RDFa is machine readable. The machine simply needs to
understand RDFa. Thus, if the user agent is committed to RDFa, it should
be able to interpret RDFa content; giving the content an option to
clarify matters re. whether an IRI is Name or Address.
If I use the
identifier today, it has to be interpreted as "I talk about that
particular IRI (an HTML document)".
No, that's only true if you interpret what HTTP is accurately relaying
to you re. your quest for a Document, as the end of the matter.
You to HTTP Server: GET me a Document at URL
HTTP Server: Found it (200 OK) or look somewhere else (30X).
You read the document and find out its about a 'Toucan'. You (in human
mode) disambiguate without even knowing it. If a user agent (machine)
retrieves the same Document, it should be able to understand what the
Document is about, and that includes the fact that the URL isn't an
Address it was used as a Name, thus said user agent will not walk or be
exposed to a relational property graph where Document properties are
incoherently intermingled with 'Toucan' properties.
Tomorrow, Amazon starts to serve
RDFa and states that this particular IRI represents a book with the
name A and the ISBN X. The status code does not change, but the
interpretation of the IRI changes.
Well an RDFa agent that is Linked Data aware should be fine, if its
dog-foods i.e. processes the self-describing data it retrieves :-)
Further, if status codes rule the interpretation of an IRI, an IRI can
either be a NIR or an IR but not play both roles.
HTTP Status Codes rule (correctly) for Document location
(Content-Location) and Document Content retrieval (Content-Type).
If I want to make an
statement like
"I don't like design of the HTML page located at
<http://www.amazon.com/Identity-Crisis-Brad-Meltzer/dp/1401204589/>"
I cannot do that, since the IRI represents either a book or a HTML
page.
Depends on the semantic-fidelity that you or your Linked Data aware user
agent commit to .
[...]
You can work with DBpedia offline, assuming you install Virtuoso +
DBpedia data from a USB to your local drive. It will work absolutely fine.
Of course I can work with DBpedia offline even without having Virtuoso
installed. The question was: Do all need all these fancy status codes?
If I need the status codes, I need to access each IRI to interpret it
correctly.
Again, my response stands. That's the case re. Virtuoso. You are saying:
I haven't experienced that. Hence my insistence re. Virtuoso.
You can explore the DBpedia data sets via HTML pages using:
http://localhost/describe/?uri=<some-dbpedia-entity-uri>, for instance.
If I don't need the status codes, it should be pretty meaningless if I
get a the status code 200 or 303 from a resource.
Virtuoso makes full commitment to Linked Data and associated
semantic-fidelity expressed in the data.
Since you said
"""
The 303 heuristic is how Name | Address disambiguation is handled re.
Linked Data.
"""
I seem to need the status codes. An algorithm cannot look at the
DBpedia data and tell me what's meant as IR and what's meant as NIR
without status codes.
Virtuoso != Apache.
You might be better off just trying what I say :-)
Best regards,
Lars
--
Regards,
Kingsley Idehen
President& CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
