Added og:mime_type_str . #4

Closed
wants to merge 8 commits into
from

Projects

None yet

2 participants

@ptarjan
Contributor
ptarjan commented Oct 20, 2011

Should all of these be namespaced somehow? I don't want someone to write

<meta property="og:mime_type_str" content="..." />
@jrweave
Contributor
jrweave commented Oct 20, 2011

Yes, that would be a mistake on the part of the user, but we should do our
best to prevent misuse. Two possible solutions:

  1. A common convention in the semantic web community is to start property
    (local) names with lower case (e.g., og:url) and to start class/datatype
    (local) names with upper case (e.g., og:Mime_type_str). We could abide by
    this convention if you think it is sufficient to prevent confusion. (It's
    good enough for me.)
  2. A whole other namespace seems excessive to me, but it is an option.
    However, we would then have to deal with the dereferencing problem, which
    could be solved (in the easiest way) using 301-redirection. For example, if
    we did define prefix ogdt to be something like http://ogp.me/ns-dt (or
    whatever), then we could define ogdt:mime_type_str and have the URI
    301-redirect to http://ogp.me/ns where it is defined.

On Thu, Oct 20, 2011 at 2:47 PM, Paul Tarjan <
reply@reply.github.com>wrote:

Should all of these be namespaced somehow? I don't want someone to write

Reply to this email directly or view it on GitHub:
#4 (comment)

@ptarjan
Contributor
ptarjan commented Oct 23, 2011

Hmm...

Maybe I'll describe what I think I want, and you tell me if that works:

  1. I don't want any markup to change on any user's page because of this. This is only for semantic web people.
  2. We should be consistent with whatever everyone else is doing.
  3. If we are going to do this, we should probably do this for everything? I made a little table http://ogp.me/#bool. Should that be encoded for the semantic web guys?

Maybe http://ogp.me/ns#type_boolean

or something like that? Or is there an already defined namespace for this we can just re-use?

@jrweave
Contributor
jrweave commented Oct 23, 2011

Hi Paul.

Regarding #1. Absolutely, the markup will not change. That is the point in
stating that {og:mime_type_str rdfs:subClassOf xsd:string} is to keep the
markup the same (which specifies plain literals implicitly understood to be
typed xsd:string in RDF 1.1) while making as much sense as possible in RDF
world.

Regarding #2. There is weak consensus that local property names should be
camel case and local class/datatype names should be capitalized camel case.
However, it really doesn't matter. OGP already breaks convention. For
example, og:image:width, I think most semwebbers wouldn't feel too good
about that second colon. og:site_name might more commonly be called
og:siteName. What is more important, though, is to choose a convention for
your namespace and just be consistent. OGP clearly chooses all lowercase,
underscore-separated words for local property names. Since OGP does not
have any class/datatype URIs, no convention has been established. I would
propose using capitalized camel case making it the exact opposite of the OGP
convention for local property names (e.g., og:MimeTypeStr clearly doesn't
look like a property), but really, whatever you prefer would be fine. Just
be consistent.

Regarding #3. Yes, it would be a good idea to define ranges of the
properties in RDF. Off the top of my head, here are some alignments:

  • og:Boolean == xsd:boolean
  • og:DateTime (if no timezone, I think < xsd:dateTime; otherwise, no
    known alignment)
  • Enums would best be defined with owl:oneOf.
  • og:Float == xsd:double? xsd:double maps to [IEEE
    754-1985]http://www.w3.org/TR/xmlschema-2/#ieee754values, so we'll
    need to know what og:Float maps to.
  • og:Integer == xsd:int
  • og:String < xsd:string (since og:String is restricted to UTF-8)
  • og:URL < xsd:anyURI (since URLs are a subset of URIs)

For the ==, there is the option of defining your own datatype (e.g.,
og:Boolean) and declaring it owl:equivalentClass the aligned datatype (e.g.,
xsd:boolean) or simply reusing the aligned type instead (which I favor).
For the <, that is simply a rdfs:subClassOf triple.

If you like, I can hack something out for you when I get the chance,
probably this week, and you can take a look at it.

-Jesse

On Sun, Oct 23, 2011 at 2:13 PM, Paul Tarjan <
reply@reply.github.com>wrote:

Hmm...

Maybe I'll describe what I think I want, and you tell me if that works:

  1. I don't want any markup to change on any user's page because of this.
    This is only for semantic web people.
  2. We should be consistent with whatever everyone else is doing.
  3. If we are going to do this, we should probably do this for everything? I
    made a little table http://ogp.me/#bool. Should that be encoded for the
    semantic web guys?

Maybe http://ogp.me/ns#type_boolean

or something like that? Or is there an already defined namespace for this
we can just re-use?

Reply to this email directly or view it on GitHub:
#4 (comment)

@jrweave
Contributor
jrweave commented Oct 24, 2011

But come to think of it, none of those datatype alignments will work (except
for og:String) since everything needs to subclass xsd:string. No problem...
we could just do it the same way as with og:mime_type_str (or
og:MimeTypeStr).

-Jesse

On Sun, Oct 23, 2011 at 6:54 PM, Jesse Weaver jrweave@gmail.com wrote:

Hi Paul.

Regarding #1. Absolutely, the markup will not change. That is the point
in stating that {og:mime_type_str rdfs:subClassOf xsd:string} is to keep the
markup the same (which specifies plain literals implicitly understood to be
typed xsd:string in RDF 1.1) while making as much sense as possible in RDF
world.

Regarding #2. There is weak consensus that local property names should
be camel case and local class/datatype names should be capitalized camel
case. However, it really doesn't matter. OGP already breaks convention.
For example, og:image:width, I think most semwebbers wouldn't feel too good
about that second colon. og:site_name might more commonly be called
og:siteName. What is more important, though, is to choose a convention for
your namespace and just be consistent. OGP clearly chooses all lowercase,
underscore-separated words for local property names. Since OGP does not
have any class/datatype URIs, no convention has been established. I would
propose using capitalized camel case making it the exact opposite of the OGP
convention for local property names (e.g., og:MimeTypeStr clearly doesn't
look like a property), but really, whatever you prefer would be fine. Just
be consistent.

Regarding #3. Yes, it would be a good idea to define ranges of the
properties in RDF. Off the top of my head, here are some alignments:

  • og:Boolean == xsd:boolean
  • og:DateTime (if no timezone, I think < xsd:dateTime; otherwise, no
    known alignment)
  • Enums would best be defined with owl:oneOf.
  • og:Float == xsd:double? xsd:double maps to [IEEE 754-1985]http://www.w3.org/TR/xmlschema-2/#ieee754values, so we'll need to know what og:Float maps to.
  • og:Integer == xsd:int
  • og:String < xsd:string (since og:String is restricted to UTF-8)
  • og:URL < xsd:anyURI (since URLs are a subset of URIs)

For the ==, there is the option of defining your own datatype (e.g.,
og:Boolean) and declaring it owl:equivalentClass the aligned datatype (e.g.,
xsd:boolean) or simply reusing the aligned type instead (which I favor).
For the <, that is simply a rdfs:subClassOf triple.

If you like, I can hack something out for you when I get the chance,
probably this week, and you can take a look at it.

-Jesse

On Sun, Oct 23, 2011 at 2:13 PM, Paul Tarjan <
reply@reply.github.com>wrote:

Hmm...

Maybe I'll describe what I think I want, and you tell me if that works:

  1. I don't want any markup to change on any user's page because of this.
    This is only for semantic web people.
  2. We should be consistent with whatever everyone else is doing.
  3. If we are going to do this, we should probably do this for everything?
    I made a little table http://ogp.me/#bool. Should that be encoded for the
    semantic web guys?

Maybe http://ogp.me/ns#type_boolean

or something like that? Or is there an already defined namespace for this
we can just re-use?

Reply to this email directly or view it on GitHub:

#4 (comment)

@ptarjan
Contributor
ptarjan commented Oct 28, 2011

so we would have og:url and og:URL? That sound nuts.

Can we make a new namespace? ogpropertytype:URL?

@jrweave
Contributor
jrweave commented Oct 28, 2011

Sure, a different namespace is an option. Personally, I wouldn't choose
"ogpropertytype", but rather something like "ogtype" or "ogclass".
"ogpropertytype" will be confusing to RDFers since properties can have types
(e.g., owl:InverseFunctionalProperty is a "type" of property) and ranges
(e.g., xsd:string could be the expected value for a property). TMTOWTDI.

-Jesse

On Thu, Oct 27, 2011 at 8:39 PM, Paul Tarjan <
reply@reply.github.com>wrote:

so we would have og:url and og:URL? That sound nuts.

Can we make a new namespace? ogpropertytype:URL?

Reply to this email directly or view it on GitHub:
#4 (comment)

@ptarjan
Contributor
ptarjan commented Oct 28, 2011

We have og:type so I don't want ogtype. Remember, most people using this stuff have no idea what the semantic web is.

ogclass sounds ok. Is there a standard URI? http://ogp.me/ns/class#?

@jrweave
Contributor
jrweave commented Oct 28, 2011

Good point about the og:type/ogtype. I don't think there is a "standard"
way. http://ogp.me/ns/class# makes sense to me, but we will have to make
sure to handle dereferencing by making the RDF retrievable (with 200, 301,
or 302) from http://ogp.me/ns/class.

-Jesse

On Thu, Oct 27, 2011 at 8:49 PM, Paul Tarjan <
reply@reply.github.com>wrote:

We have og:type so I don't want ogtype. Remember, most people using
this stuff have no idea what the semantic web is.

ogclass sounds ok. Is there a standard URI? http://ogp.me/ns/class#?

Reply to this email directly or view it on GitHub:
#4 (comment)

@ptarjan
Contributor
ptarjan commented Nov 1, 2011

Ok, sure. If you update the pull request with the namespace ttl file that would be nice too. You can probably just run this whole project on a normal php webserver.

@ptarjan
Contributor
ptarjan commented Dec 12, 2011

Are you going to update this or should we close it out?

@jrweave
Contributor
jrweave commented Dec 12, 2011

Got caught up in other work, but I'll get it done this week.

On Sun, Dec 11, 2011 at 11:49 PM, Paul Tarjan <
reply@reply.github.com

wrote:

Are you going to update this or should we close it out?


Reply to this email directly or view it on GitHub:
#4 (comment)

@jrweave
Contributor
jrweave commented Dec 12, 2011

That should do it. Give it a look and see if that's what you had in mind. Note that the changes add explicit semantics to the OG properties WITHOUT requiring additional RDFa markup. Also, you will need to set up http://ogp.me/ns/class to 302 to http://ogp.me/ns . Let me know if there are any questions, comments, revision requests, etc.

@ptarjan
Contributor
ptarjan commented Dec 19, 2011

Looks good. I don't really understand the nuances between ogc:string and xsd:string but you're more an expert in this space than I.

You should be able to setup the 302 from this repo since the whole ogp.me is here.

Also, this pull request can't be merged. Can you do a rebase onto the current HEAD so I could auto-merge it?

@jrweave
Contributor
jrweave commented Dec 19, 2011

So I am not very github savvy. What exactly is it that you're asking me to do? I can't find much documentation on rebasing with github. I have made all my changes in the browser without actually using git locally.

@ptarjan
Contributor
ptarjan commented Dec 20, 2011
git fetch origin
git rebase origin/master

(assuming you have github repo set as origin)

@jrweave
Contributor
jrweave commented Dec 20, 2011

Done.

@ptarjan
Contributor
ptarjan commented Dec 21, 2011

and then you have to somehow get it back to this pull request. Maybe a git push

@jrweave
Contributor
jrweave commented Dec 21, 2011

Done. "Everything up-to-date".

@ptarjan
Contributor
ptarjan commented Dec 21, 2011

Well the button still tells me it can't be automagically merged.

You can check this diagram to see if it still shows you aren't based on the most recent commit to the root repo. (when the page gets fixed)

@ptarjan
Contributor
ptarjan commented Dec 21, 2011

Ok, I took care of it for you.

Next time, please don't retab the whole damn thing. That makes merging horrible.

@ptarjan ptarjan closed this Dec 21, 2011
@jrweave
Contributor
jrweave commented Dec 21, 2011

Hmmm... I don't recall retabbing the whole thing.

On Tue, Dec 20, 2011 at 9:06 PM, Paul Tarjan <
reply@reply.github.com

wrote:

Ok, I took care of it for you.

Next time, please don't retab the whole damn thing. That makes merging
horrible.


Reply to this email directly or view it on GitHub:
#4 (comment)

@jrweave
Contributor
jrweave commented Dec 21, 2011

I think the problem is that

8b40b59

occurred after I forked, and thus the inconsistency. I had intentionally used tabs to be consistent with the rest of the file. I assure you, had it been spaces instead of tabs, I would have used those instead. (Perhaps this was the source of our inability to automagically merge?) Sorry for the pain.

@ptarjan
Contributor
ptarjan commented Dec 21, 2011

@jrweave no worries. Someone had to do the merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment