Re: httpRange-14 Change Proposal

Perhaps I am reading it wrong... maybe the NLI proposal is what it
says it is: There is no default, there is only content opt-in and RDF
description opt-in. If the content from U does not contain either <U>
describedby {something} or {something} describedby <U>, then <U>
should not be written by someone who cares how <U> will be interpreted
(and if they don't care I don't know why they would write it at all).
For the Creative Commons embedded metadata use case, the provisioning
CMS adds to the content either

[] describedby <U>.

or

<U> describedby <U>

as long as this doesn't conflict with a <U> describedby ... statement
added by some other module of the CMS. (The way the URI is being used
would have to be coordinated among all modules contributing RDF to the
content.)

For the OGP use case, Facebook adds

<U> describedby [].

to the content (again, assuming no conflict with other CMS modules).
Therefore no second URI, so useful for metadata writers but so
annoying for provisioners, needs to be deployed. The same could be
done with Proposal 25: for the OGP case provide a header

Document: tag:rees@mumble.net,2012-04-24:unresolvable

Then to refer to the OGP web page to talk about it, we're back to

[w:contentUri "U"] xhv:license
<http://creativecommons.org/publicdomain/zero/1.0/>

since the tag: URI is useless.

Under NLI the contextUri syntax or something similar would have to be
used to talk about any web page that doesn't contain {something}
describedby <its URI>, that is the 99.9999999 percent.

If I were writing a CMS, provenance tracker, etc. I wouldn't want to
bother with coordinating uses of <U> and would simply write
[w:contentUri "U"] for all embedded metadata. This is what CC's
documentation and license chooser will need to prescribe should NLI or
Proposal 25 be adopted.

This presents a bit of a problem for RDF graphs retrieved from a URI U
which don't contain describedby <U>, e.g. all the ones generated by,
say, Protege. If you want to refer to the graph you're also stuck
using [contentUri "U"], or else modifying Protege (which obviously
will only work for new files, not retroactively), or making
owl:Ontology a subclass of the range of describedby, etc.

I thought about the possibility of 'squatting' and locally
constraining the meaning of <U> via a describedby <U> statement in the
message (i.e. the thing containing the RDF, not the content served).
This doesn't work, however, if the content doesn't describe anything
(describedby would be a lie), and it also poses interoperability risk
in the case <U> describedby ... is added to the content later.

This suggests a slightly different but more orthogonal and transparent
proposal: two types, one for linked data and the other for web pages
(not necessarily disjoint). Write
  <U> rdf:type w:LinkedDatum
instead of
  <U> describedby []
and
  <U> rdf:type w:InformationResource
instead of
  [] describedby <U>
(where w:InformationResource is a somewhat less informative type
including things whose content doesn't describe anything).

Personally it's not to my taste to express this as a type distinction
on <U> as it's really a property of the URI, not its interpretation; I
would write
  <U> w:descriptionUri "U".
and
  <U> w:contentUri "U".
but I'm trying to go with the flow...

Is this fair? I'm just trying to work through the consequences of the
various proposals so they can be compared (action-691), and I find it
all very confusing.

Jonathan

finally got around to this:
@prefix w: <https://www.w3.org/2001/tag/2012/04/issue57#>.

Context for CC's benefit:
http://lists.w3.org/Archives/Public/www-tag/2012Mar/0086.html
http://www.w3.org/wiki/HTML/ChangeProposal25

Received on Tuesday, 24 April 2012 22:35:15 UTC