Re: Vocab terms for owner, validFrom and validUntil

On 4 May 2012 15:58, Manu Sporny <msporny@digitalbazaar.com> wrote:
> On 05/04/2012 01:44 AM, Dan Brickley wrote:

>>> We have created 3 terms for the PaySwarm vocabulary that we think
>>> may be better off in the rdf or rdfs vocabulary. They have to do
>>> with "resources" on the Web.
>>
>> What's a "resource"?
>>
>> rdfs:Resource is a synonym for the word Thing; nothing isn't one.
>
> Basically, an rdfs:Resource. Yes, nothing isn't one... except for
> nothing, which isn't one. :P

So you're not scoping this, they have to do with everything?

>>> The first is the canonical "owner" of a resource on the Web. Keep
>>> in mind that this is different from dc:creator and those types of
>>> expressions. It could be used to establish the owner of a financial
>>> account (that uses a web address), a public key that is published
>>> to the Web, or a variety of other pieces of information that
>>> "belong" to an IRI identifier (like a person's identifier).
>>
>> Do these diverse examples ever disagree, overlap?
>
>
> What do you mean by "disagree"? Are you asking whether two things could
> state two different things about who their owner is?

Because the examples were quite varied, my concern was that two of
these different notions of 'owner' could kick in for the exact same
thing, and give different answers.

> If so, then yes - just like any other statement in RDF.
>
> Are you asking if the concept of an "owner" is subtly different in each
> of these cases - perhaps, but when we have that case, we become more
> specific and create a new vocabulary term - like "primaryOwner".

There was an active RDF Model and Syntax WG from 1997-1999, from 2001;
from Feb 2001 to Nov 2003. And now this group, from Feb 2011 to ...
well let's see ... our charter has
http://www.w3.org/2011/01/rdf-wg-charter  "January 2012: Publication
of all final documents" ... looks like a typo for Jan 2013.

How would you go about adding in new clarifications to owner /
primaryOwner after the WG closes? Ask Ivan nicely? The rhythm and pace
of updates to RDF don't lend themselves to application-level
vocabulary hosting, I'm afraid. It's a one-shot 'let's get this right,
or wait 5 years' kind of a deal.

>> Who 'owns' my Facebook account?
>
> Facebook.

See also http://www.technolog.msnbc.msn.com/technology/technolog/lawsuit-raises-who-owns-your-twitter-account-issue-118259

>> W3C user account?
>
>
> W3C, I presume.
>
>> An apartment i'm renting
>
> The person that has legal dominion over the apartment.
>
>> or a page about it?
>
> The person that owns the copyright on the page.
>
>> A wiki page?
>
>
> Depends on the license, but most likely the community, the public
> domain, or the company that runs the wiki.
>
>> My user page on a wiki?
>
> Same as above.

For each of the above, why is it more important to the Web community
(ie. why do we bake supporting vocabulary into the core of RDF) to
know those things, rather than --- for example --- subject / taxonomy
information?

>> Do some things not have such an owner?
>
>
> Some things don't have an owner - like the earth, or the concept of honor.
>
>> Can ownership be joint, either by the owner being a group or abstract
>> agent, or by 2+ things being in that relationship at same time?
>
> Yes, and I don't see why not.

That design choice affects how consuming parties deal with seemingly
conflicting information. If 'foo:owner' is functional, then there's at
most one 'thing' that is some other thing's owner (though the owner
might be an aggregate entity like a group, organization or company).
So if I'm told ENTITY_102 is the owner of thing X, and I'm told that
ENTITY_511 is the owner of X, then I'm compelled to either assume
they're the self-same entity, or else that these claims contradict
each other. Depending on application scenarios, this can be a useful
characteristic of a vocabulary.

>>> The second and third are validity periods for particular pieces of
>>>  information - like when is an offer for a good or service valid
>>> from/to? When was a home address valid from/to? When was a public
>>> key valid from/to?
>>
>>
>> By valid, do you mean true? Is the assumption that -was once not
>> true/valid -was true/valid -at some point stops being so ... is a
>> central pattern worth documenting? Even if it doesn't capture eg
>> more cyclical patterns?
>
>
> By valid, I mean that you can count on the information to be accurate
> based on what the claimant is stating.

Sorry - I don't understand what that sentence means. That I can rely
on the information, based on the information? I guess it's a bit like
'best-before' warnings on food, maybe?

> "True" is something slightly different. I do think this is worth documenting in a core "RDF
> vocabulary", even if it doesn't catch the edge cases like cyclical validity patterns.

What are the characteristics of it being in the 'core' that make it
appealing to put things there? Would rdf: vs rdfs: be better, and why
exactly? Why not add it to owl: or skos:?

In the original RDF design, we spent a lot of time saying "no, we'll
do that later ... in other vocabs and successor standards". So a lot
of the original ideas for RDFs (class-specific rules about properties,
datatypes) got postponed and left to the much later OWL standard. And
still people say RDF is too complicated :) I'm not sure we'll find
much support for adding application-level vocabulary into the core.

Something being in 'rdf:' ns has the advantage that it looks really
official and important (even if the definitions are murky, c.f.
rdf:value).

Something being elsewhere on w3.org has a similar, if weaker, benefit.
So for example http://www.w3.org/2003/01/geo/ was happily used by many
parties for months or even years until we noticed we'd not bothered to
specify the units and meaning for 'alt'. Still people preferred it to
perhaps more carefully designed vocabularies because it had that cool
w3.org domain name.

Something being on w3.org (and in rdf:) has likely longevity
advantages, ... and may see greater uptake, purely by virtue of it
looking more standard and important. But that's balanced by the
bureaucracy / complexity of getting revisions and changes deployed.
After 15 years, there is still no clear explanation of rdf:value in
the ns doc beyond 'Idiomatic property used for structured values'.

>>> When describing resources on the Web, these three items seem like
>>> they'd be vital for establishing ownership and information
>>> validity periods. Should they go in the RDF or RDFS vocabulary?
>>
>> Why elevate these use cases above others?
>
>
> Because they are core to many different types of usages of RDF.
> Ownership is a universal concept, so is validity of statements made.

So is aboutness of documents, so is community, and so is the notion
that two class definitions have no common members. Each of these can
be addressed within the RDF community; none of these need to be
directly included in rdf: itself (or rdfs:).

The problem with truly universal concepts (love, friendship,
ownership, ...) is that they mean something to each of 7 billion
people, and there are vast differences across those uses. Most of the
concepts in rdf: and rdfs: have pretty specific meaning, ideally
characterised formally.

Regarding validity of statements, you might look at the recent large
batch of docs from the Provenance WG. They've put a considerable
amount of work into finding commonalities across different notions of
information provenance, and the results are worth a look -
http://www.w3.org/blog/SW/2012/05/04/the-prov-ontology-an-update/  -
but they also show how large the design space is. How would we know
we'd picked the right tiny fragment to include in RDF/S? You want
something less vague than Dublin Core, and less detailed than Prov,
maybe. But how to know we'd got that balance right?

>> For example, describing what a  piece of information is 'about' is
>> quite important too. Why not add dc:subject plus SKOS into the core?
>>
> That's another discussion, which I'm not interested in having (but is
> worth having). We have never used dc:subject, nor have we ever used
> SKOS. That sort of meta-modeling is something that we have not found
> useful for the purposes of the Web Payments work.

My point is, why prioritize the capitalistic use case over the
information discovery use case? Why not just put everything of general
utility into rdf: core? (or, yup, rdfs:, nearby...)

>> Or the most useful bits from OWL?
>
> We've never had to resort to using OWL except for stuff like owl:Thing.
> It's been largely not useful to our work on Web Payments.

Ok. But you're not explaining (other than you thought it worth asking
just in case) why you'd expect the W3C RDF WG to add stuff to support
your application use cases directly in the rdf: or rdfs: vocabularies?
Other than that they deal with matters of ownership, which is of
course by its very nature a multi-gazillion dollar industry and
therefore very important...

We'd need a lot more to support going from 'it's important' to 'it
should be in rdf: core ns'.  One might argue that such important
things deserve to be managed as first class efforts in their own
right, rather than squeezed into other projects.

>> Do you have draft schema definitions for these proposals?
>
> Not yet, but I could create them. I wanted to pass it by this group to
> see if it was something that was of interest.

I suspect (others are yet to comment) you'll find enthusiasm for the
topic, and very little for the specific proposal of adding these terms
to the main rdf namespace.

>> Historically rdf/rdfs vocab has been kept pretty minimalist. I doubt
>> you'll find much enthusiasm for changing that policy at this stage
>> (including rechartering WG etc).
>
> It would be nice to not have to re-charter a group to add a few
> vocabulary terms to a vocabulary.

Sure. There are lots of RDF vocabularies that are not as locked down
as this one. Most, I'd imagine. Vocabularies that are far more open to
rapid adoption of updates and improvements from the community, and
incremental tweaks.

> This is exactly what we were afraid of happening when we discussed this on the PaySwarm call:
>
> http://payswarm.com/minutes/2012-05-01/#topic-1

Reading that, it sounds like anything on w3.org would cover your needs.

>> That said I'd be happy to pick up this thread with a schema.org or
>> FOAF hat on; there are important distinctions lurking here and worth
>> having in a mainstream schema somewhere.
>
> Please don't put it in schema.org and please don't put it in FOAF - this
> is far more integral to the core of how we describe things on the Web.
> Who owns a resource and for how long are the statements associated with
> a resource valid.

Should dcterms:valid be deprecated too, then? It's a pity we spend all
this time making decentralising technology, only to drift back to 'the
only good namespace is a W3C one'-ism.

But I say that as a guy working on a pretty big centralised vocab, so
who knows... I see the appeal of having things in one place, and
http://www.w3.org/2011/rdfa-context/rdfa-1.1.html is quite an
interesting middle-ground in terms of central-vs-decentralised.

Anyway, say we did decide to add this... and the specs went out for
final review later this year. What would an expert spec reviewer at,
for example, Apple or PayPal or Adobe or ... (to pick from
https://www.w3.org/Member/ACList ...) be expected to make of
rdf:owner? How would their approach to reviewing the near-final RDF
specs change, if it moved into such territory? Would lawyers pick over
the definitions, ... talking with product managers and engineers to
figure out whether this specific notion of 'owner' fitted with their
business plans? I'm concerned that such an addition strays so far from
the core chartered business of this group that it would risk
standardising a definition that we couldn't do decent QA for, that our
likely RDF-centric reviewers wouldn't know how to review properly, and
that W3C itself subsequently wouldn't know how to version, improve,
evolve. Although it might be less 'standard', I expect a more informal
effort on a w3.org namespace (if that's what you need) incubated via
Community Group would be a much more rewarding path, and likely have
higher quality results with greater impact.

cheers,

Dan

Received on Friday, 4 May 2012 15:31:45 UTC